From the web page
http://www.austin.ibm.com/sns/guidelines.htm

    Guidelines

Successful access to information and use of information
technology by people who have disabilities is known as
"accessibility". Following these guidelines and using these
tools will ensure developers and content providers understand
why and what they need to do to make all of their technology and
information accessible to people who have disabilities. Please
read the sections below on " Needs of users who have
disabilities" and " Why accessibility" to get a good background
awareness of the concerns. 

 Accessibility Guidelines

Software Accessibility
  * Overview of accessible software
  * Principles of accessible software
  * Checklist for software accessibility, version 2.1
  * References and resources.

Web Accessibility
  * Checklist for Web accessibility, version 2.1
  * Rationale, Techniques, Testing
  * References and resources.

Java tm Accessibility
  * Checklist for accessible Java applications, version 2.1
  * Guidelines for writing accessible Java applications
  * References and resources.

Lotus Notes Accessibility
  * Checklist for accessible Lotus Notes applications, version
    2.1
  * References and resources.

Hardware Accessibility
  * Checklist for accessible hardware, version 2.1
  * Guidelines for accessible hardware
  * References and resources.


Needs of users who have disabilities

Meeting the standards of accessible software first requires an
awareness of the special needs of users who have disabilities.
The blind cannot use a mouse because it is a hand-eye
coordinated device, so every application must be operable with
just the keyboard. The blind and others with dyslexia and
low-vision also rely on assistive technology know as a screen
reader that reads the screen's information, controls, buttons,
and text to the user. Today's screen readers transform the
visual interface into an audio interface that the blind and
others can use.

Those users with low-vision and color blindness have difficulty
perceiving information that is presented by differences in
color, contrast, depth, size, location or font differences
alone. A good example would be when both color and a fill
pattern is used to denote different bars on a graph so they can
be when viewed in either color or black and white. A poor
example would be using only the size attribute in HTML to denote
a heading; the heading element tag should be used to correctly
mark-up the structure of the Web page.

The deaf and hard of hearing have many of the same needs as
those users who do not have a sound card or who work in a noisy
environment and need information presented visually in addition
to the audio means. For example, closed captions, blinking error
messages, and transcripts of the speaking audio are necessary
for the deaf and hard of hearing.

The users with hand, arm, and other mobility impairments may not
be able to use multiple simultaneous key strokes such as
Ctrl+Alt+Del and therefore rely on special keyboard enhancements
in the operating system. Some users must rely on voice input and
navigation where possible. Others rely on changing settings to
allow them time to enter the information at their own pace, one
keystroke at a time. The developer and Web page author do not
have to figure out how all the different people with
disabilities will use their information technology if they
follow these established guidelines and checklists.

Why accessibility?

The rights of disabled employees includes access to information
to be able to do their jobs. The purchasing requirements of
government agencies and large corporations require accessible
software. These rights and requirements are being established in
legislation around the world similar to the United States's
Americans With Disabilities Act (ADA) and the Telecommunications
Act. An additional reason to meet these standards and guidelines
of accessibility comes from the benefits derived. All users
benefit when they can use voice navigation, all test groups can
benefit when they can automate complete test cases via the
keyboard, and all Web authors can benefit when the same Web page
can to viewed, printed, listened to, or browsed in Braille with
no extra work by the author.

IBM has a tradition of leading the industry in providing
accessible technologies to people who have disabilities. We are
sharing our guidelines with developers of hardware, software,
Javatm, and Web solutions. Please use the resources found on
this page to produce accessible solutions. You are also invited
to give us feedback.

----------
>From the web page
http://www.austin.ibm.com/sns/accesssoftware.html

Software accessibility

Software comes in tremendous variety. There are editors,
integrated development environments, presentation tools, word
processors, spread sheets, notes database applications and web
based solutions, to mention just a few. This document will
provide the information that software developers need to make
their software accessible to people who have disabilities.

Table of Contents:

Overview of accessible software

Principles of accessible software

Checklist for accessible software

References and resources

It is not surprising that most software developers have never
stopped to imagine a blind person using their product. It is
inconceivable. How about a person who has no arms? No way! But
these people and many others with a tremendous variety of
disabilities expect to use this tremendous variety of software
just as their non disabled colleagues do.

The key to the mystery of how people with severe disabilities
could use a computer application is that they use what is called
assistive technology. As a developer you don't have to worry
about making your application talk, the blind user will have a
screen reader, and the screen reader will do the talking. But,
and it is a big 'but,' you do have to make sure that the screen
reader can find the information that it needs to do the talking.
A blind person can't use a mouse, so you'll need to make sure
that anyone can use your software with just the keyboard. Unplug
the mouse and try! There is some work that you the programmer
will have to do to provide access from the keyboard and to be
sure that all the necessary information is available to the
screen reader.

As an application software developer, you don't have to figure
out how a person without arms will provide input to your
application. There is assistive technology that the disabled
person can use to provide keyboard input to your program. Speech
input is another choice, and for that, all program features must
be easily accessible from the keyboard. Keyboard access is
essential for blind users, mobility impaired, and those choosing
to use voice input.

Sometimes assistive technology is unnecessary. Did you know that
people with some forms of limited vision may be absolutely
incapable of reading text on the usual black and white screen
and yet be able to read the screen with the colors reversed, or
even better, with yellow letters on a blue background? Such
people don't need assistive technology if they can just change
the background and foreground colors in the software.

Most of the recommendations for accessibility are
recommendations for good user interface design.

These 3 basic principles should be followed when developing
software.


Choice of input methods

Support the user's choice of input methods including keyboard,
mouse, voice, and assistive devices via the serial port. The
primary requirement is to provide keyboard access (mouseless
operation) to all features and functions of the software
application. The operating system usually provides support for
input via the serial port, keyboard movement of the mouse
pointer, and other keyboard enhancements.


Choice of output methods

Support the user's choice of output methods including display,
sound, and print. The primary requirement is to provide text
labels for icons, graphics, and user interface elements and to
support visual indications for sounds. Implementing the
accessibility APIs (e.g., Java Accessibility, Microsoft Active
Accessibility, etc.) for the target platform will meet this
principle.


Consistency and flexibility

Make the application consistent with the user's choice of system
behavior, colors, fonts sizes, and keyboard settings. Provide a
user interface that can be customized to accommodate the user's
needs and preferences including fonts, colors , and display
layout.



IBM Software Accessibility Checklist - Version 2.1

January 11, 2000


* *This checklist was originally based on the "Requirements
for Accessible Software Design," Version 1.1, March 6, 1997,
published by the US Department of Education:
http://ocfo.ed.gov/coninfo/clibrary/software.htm We have drawn
heavily on the Microsoft Windows Guidelines for Accessible
Software Design for rationale and techniques.

1.1 Keyboard equivalents

Provide keyboard equivalents for all mouse actions.

1.1 Rationale.

Users with a mobility impairment may not be able to use the
mouse because of the fine motor control required to move the
mouse. Users who are blind cannot use the mouse to navigate
software because it depends on visual feedback of the location
of the mouse pointer. Therefore, it is important to make all
mouse actions available through the keyboard. This includes
access to menus, toolbars, buttons and links. Providing a good
keyboard user interface is key to designing an accessible
application.


1.1 Techniques.


* Here is a document with Keys used in Windows. Applications
should be consistent with, and not interfere with, those keys
found throughout the operating system. The Microsoft Design
Guide includes Appendix B Keyboard Interface Summary, which
contains both operating system specific key commands, like
Ctrl+Alt+Del, and recommendations like ALt+F4 for close window,
and Ctrl+P for Print.


* In dialogs, allow the user to press the TAB key to move the
focus through the "hot spots" or active regions and to press the
ENTER key to choose the currently selected active region. The
SHIFT+TAB key combination is used to move backwards through
dialog. Use arrow keys to move between controls within a group
of controls.


* Provide keyboard commands (F6 or CTRL+TAB) to move between
window areas. For example, in Microsoft Windows' Multiple
Document Interface (MDI), use the F6 key and the CTRL+TAB key
combination to move the focus between panes and child windows.


* Windows software that normally hides some keyboard user
interface elements or omits some keyboard mechanisms altogether
should present them when the Keyboard Preference flag is set.
This flag, which is set by the user in Control Panel
(Accessibility Options/Keyboard/Show extra keyboard help in
programs), advises an application that the user relies on the
keyboard rather than a pointing device, so additional support
should be provided where appropriate. An application can test
for this flag by calling the SystemParametersInfo function with
the SPI_GETKEYBOARDPREF value.


1.1 Testing.

Unplug the mouse and navigate to each feature using the keyboard.


1.2 Document Keyboard Access

Follow documented operating system conventions for keyboard
access. Document keyboard access that is unique to the product.

1.2 Rationale.

Since most software is mouse driven, it may not be clear how to
access functions using the keyboard. Without this documentation,
you cannot use the software with the keyboard. Documentation
should include menu access, keyboard navigation, and keyboard
shortcuts. It is not necessary to document the keyboard access
for those functions which follow documented operating system
conventions. For example in Windows software, Tab moves through
a dialog, Alt+Tab moves through windows, Alt+F4 closes a window
and usually, Ctrl-O opens a document, Ctrl-S saves the document
and Ctrl-P prints the document.


1.2 Techniques.


* The Microsoft Windows Design Guide includes Appendix B
Keyboard Interface Summary, which contains both operating system
specific key commands, like Ctrl+Alt+Del, and recommendations
like ALt+F4 for close window, and Ctrl+P for Print.


* Provide keyboard accessibility documentation in the product
help. Include a keyword search for accessibility, disability,
and keyboard for easy identification.


* Provide index entries for accessibility, disability and
keyboard.


* In the product documentation, include a section called
"Keyboard access" where all accessibility features are
documented.


* Include keyboard equivalent function in the pull-down menus.
For example, to document the shortcut key for Save,

 add Ctrl-S next to the Save command in the File pull-down menu.
Accelerator keys for menu items, indicated by the underline in
Windows, F for File, are "self documenting."


1.2 Testing.

  * Open the software help menu. Search on the words keyboard,
    accessibility or disability. Verify keyboard support is
    documented in the help facility.
  * Open the software documentation. Search on the words
    keyboard, accessibility or disability. Verify keyboard
    support is documented in the product documentation.
  * If the product provides "how to" instructions and/or
    context-sensitive help, verify that they include how to
    perform actions using the keyboard in addition to using the
    mouse?
  * Open the software documentation. Search for "click" and be
    sure that the corresponding keyboard activation is
    documented along with the mouse action.


1.3 Accelerator, mnemonic or shortcut keys

Define accelerator, mnemonics or shortcut keys for tasks that
are frequently performed (e.g., Ctrl+P for print, Escape for
cancel).

1.3 Rationale.

Users who are blind or have certain motor disabilities must use
the keyboard to navigate an application. The decision of what
features to map can be made by determining which features are
key to the software such as functions on the task bar. People
with disabilities benefit from short cut (like Ctrl+P for Print)
because they can reduce time consuming steps that would
otherwise be required to activate the feature. For example, when
shortcut keys are provided for Print, users just press Ctrl-P.
Otherwise it takes 5-15 keystrokes to accomplish the same
action. Users must first use F10 to open the main menu, then
ENTER on the File menu item. They must then arrow down 5-10
times to get to the Print option and press ENTER. If the
accelerator key P for Print is available, the user presses F10
to open the menu bar, ENTER to select File, and then P for Print.


1.3 Techniques.

  * Except when menus are dynamic, each menu item should have an
    accelerator key and in F for File.
  * For Windows software, The Microsoft Windows Keyboard Guide
    documents the recommended keyboard user interface
    conventions. This can serve as a valuable reference when
    designing any keyboard user interface. You can download this
    document from http://microsoft.com/enable/.
  * Windows software that normally hides some keyboard user
    interface elements or omits some keyboard mechanisms
    altogether should present them when the Keyboard Preference
    flag is set. This flag, which is set by the user in Control
    Panel (Accessibility Options/Keyboard/Show extra keyboard
    help in programs), advises an application that the user
    relies on the keyboard rather than a pointing device, so
    additional support should be provided where appropriate. An
    application can test for this flag by calling the
    SystemParametersInfo function with the SPI_GETKEYBOARDPREF
    value.


1.3 Testing.

Unplug the mouse and navigate to each item on the action menu
and the action bar using the keyboard. Verify common tasks
(e.g., open, close, save, print) have shortcut keys.


1.4 Keyboard tab order

Provide logical interaction with interface objects (logical tab
order between buttons, lists, etc.).

1.4 Rationale.

A logical keyboard navigation order should be used to ensure
that dialog boxes and similar groups of objects can be traversed
in a logical order using the keyboard, normally from left to
right and top to bottom (for Western languages).

If the order does not follow this convention, it can be very
confusing to users who navigate using the keyboard. It is
especially confusing for people who are blind and rely on screen
readers. Users who are blind explore a dialog box sequentially,
instead of scanning the entire box as sighted users would;
random tab order can make the dialog box nearly unusable.


1.4 Techniques.

The tab order is the order in which the TAB key moves the input
focus from one control to the next within a dialog box. Usually
the tab order proceeds from left to right in a dialog box, and
from top to bottom.

For example, in Microsoft Visual C++ use Layout/Tab Order to
view and change tab orders or your dialogs.Use standard
programming practices for specifying the tab index for each
control in a dialog.


1.4 Testing.

Unplug the mouse and navigate forms and dialog boxes using the
keyboard. Verify the order in which objects are navigated makes
sense (usually left to right and top to bottom).


2.1 Accessibility features

Do not interfere with existing accessibility features built into
the operating system (e.g., Sticky Keys, Show Sounds, Serial
Keys).

2.1 Rationale.

Most operating systems have a set of Accessibility Options which
enable users to customize their setup for the keyboard, display,
sound and the mouse. For example, someone with a motor
disability may not be able to press multiple key strokes
simultaneously. Setting the Sticky Keys option enables them to
press the keys one at a time (e.g., Ctrl-Alt-Delete). Someone
who is deaf or hard-of-hearing would need to set the Sound
options so they get visual cues or captions for audio
information. These features make it possible for people with a
variety of disabilities to use their computer. If the software
interferes with these options these users may find their system
unusable.


2.1 Techniques.

  * Do not use keyboard sequences reserved for the accessibility
    features on your operating system.. Here are examples of
    Keyboard Mappings taken from the Windows operating system.

                                                                
           Keyboard Mappings           Mobility Access Feature  
                                                                
   5 consecutive clicks of Shift key   On/Off for StickyKeys    
                                                                
   Right Shift held down 8 seconds     On/Off FilterKeys        
                                                                
   NumLock held down 5 seconds         On/Off ToggleKeys        
                                                                
   Left-Alt+Left-Shift+PrintScreen     On/Off HighContrast      
                                                                
   Left-Alt+Left-Shift+NumLock         On/Off MouseKeys         
                                                                
  * Avoid program defined shift states, other than Shift, Alt
    and Control.


2.1 Testing.

  * On the Keyboard page of the Windows Accessibility Options
    from the Control Panel, set the "use sticky keys" option. In
    "Settings," check "use shortcut." Using only one finger,
    navigate in your application. Verify that all multiple key
    strokes (e.g., Ctrl-P for print) can be activated using only
    one finger. Activate the StickyKey feature with the
    activation keyboard command (five clicks of the Shift key in
    Windows).
  * On the Sound page of Accessibility Options, check "use
    SoundSentry." Verify that your application's system sounds
    create a visual alert.


3.1 Object focus

Provide a well defined visual focus indicator that moves among
interactive objects as the input focus changes. This focus
indication must be programmatically exposed to assistive
technology.

3.1 Rationale.

Even if the software provides keyboard access so users can
navigate the software, that isn't enough if you don't know where
you are. Keyboard users must be able to see the current focus
point to know what to do. Imagine typing if you could not see
the caret (insertion bar). Also assistive technology (e.g.,
screen readers, screen magnifiers) needs to know the position
and contents of the visual focus indicator, so it can describe,
magnify or manipulate the object for the user.

In an editing situation, the caret or insertion bar is the
visual focus. As a blind user moves the focus with the arrow
keys, a screen reader must know the position of that focus so
that it can echo the current character, word or line. Similarly,
as a user tabs around a dialog, a screen magnifier can follow
the visual focus.


3.1 Techniques.

For Windows software, the object focus can be provided through
the use of standard Windows controls, Microsoft Active
Accessibility (MSAA) programming interfaces or use of the system
caret. Each of these methods is described below. The Microsoft
accessibility team has authored a detailed guide for writing
accessible software which covers this point and many others.

The easiest way to provide object focus in Windows software is
through the use of standard Windows controls. Windows notifies
assistive technology when and window gets focus. It does this
using Active Accessibility, window hooks, and window messages.
When you use standard Windows controls no additional work is
required to provide visual focus.

If the software uses non-standard controls, Microsoft Active
Accessibility (MSAA) is the preferred method of exposing the
object focus location. The application must call NotifyWinEvent
whenever the focus moves to an object that does not correspond
to an entire window. It must handle the WM_GETOBJECT message
when that is used to query the focus object. COM objects
representing screen elements must also support the accSelection
property.

For more information about MSAA, refer to the Microsoft Active
Accessibility page.

Object focus can also be provided by positioning the system
caret on the focus object. The system caret is the blinking
vertical bar that the user sees when editing text, but it can be
placed anywhere on the screen, made any shape or size, and even
made invisible.

If the system caret is made invisible, it can be moved to
indicate the focus location to assistive technology without
disturbing what the user sees on the screen. This technique will
expose the focus to assistive technology; there still must be
some visual indication of the focus object.


3.1 Testing.

  * Unplug the mouse. Using the keyboard, navigate through the
    software, especially menus, dialogs, forms and property
    boxes. Verify the visual focus is clearly visible and easy
    to identify when you tab or arrow to the next object.
  * Run Magnifier. As you navigate through the software, verify
    Magnifier tracks the focus indicator and displays it in the
    Magnifier window.


3.2 Object information

Provide sufficient information about user interface objects so
that assistive technology can understand how the objects are
used (e.g., the object is an edit field or a check box which is
checked).

3.2 Rationale.

Users who are blind use computers with the aid of assistive
technology such as screen readers or braille displays. The
assistive software must provide information about the objects so
a screen reader can tell its user what the focus object is as
well as its role and state. For example, if you tab through a
form and focus is on a radio button object, you need to know it
is a radio button and whether it is checked or not.


3.2 Techniques.

  * The easiest way to provide object information in Windows
    software is through the use of standard Windows controls. No
    additional work is required for standard Windows controls.
  * If the Windows software uses non-standard controls, MSAA is
    the preferred method of exposing object information.
  * If the application does not support MSAA, the following
    steps can help make a control more compatible, but not fully
    compatible, with accessibility aids. If the custom control
    has its own window, you can return a descriptive string when
    the control is queried using the WM_GETTEXT message. For
    example, a control that appears as a button with the label
    Print could return the string "Print button" to convey both
    the control type and the label. The same string would be
    appropriate if the control looked like a button but had a
    graphic showing a printer rather than a textual label.
    Likewise, a custom control that behaves like a check box
    could return a caption string "Printing Enabled check box,
    checked."


3.2 Testing.

Run Object Inspector. As you position the mouse over objects,
verify that the name, role, and state fields are available
through Object Inspector. If any fields are blank or have
incorrect information, this checkpoint is not met.


4.1 Labels associated with controls or objects

Associate labels clearly and/or programmatically with controls,
objects, and icons.

4.1 Rationale.

Labels name an object (e.g., icon names, window titles, button
labels, edit fields). The labels must be associated with the
object in order for the assistive technology to make them
available to the user.


4.1 Techniques.

  * Use MSAA to expose the name and description of each image.
  * Place text labels for objects immediately to the left or
    immediately above the control. Screen readers use proximity
    to identify labels if they are not exposed programmatically.
  * Use the standard Windows tooltip control to apply a label to
    each image.
  * Avoid having multiple objects with the same name on the same
    form or dialog if they do not perform the same function.


4.1 Testing.

Run Object Inspector. As you position the mouse over objects,
verify that the name, and value fields are available through
Object Inspector. If any fields or blank or have incorrect
information, this checkpoint is not met.


4.2 Positioning related objects.

Position related objects near each other.

4.2 Rationale.

Assistive technologies (screen readers and screen magnifiers)
use proximity to help their users understand the identity and
purpose of objects. Grouping related items makes forms or
dialogs easier to comprehend and execute. In a form where a
customer enters a name and address, you would never think of
placing the State combo box before the Name entry field.
Instead, place the State combo box after the City entry field.
This not only improves accessibility for users with
disabilities, but improves the usability for all users.


4.2 Techniques.

  * Group items by function or logical association. For example,
    Name, Street, City, and state can be grouped together under
    the heading "Address."
  * Order elements by their sequence or use. For example, in an
    ordering application, group the items in the order they
    would be entered.
  * Order objects by importance with the most important fields
    at the beginning of the group.
  * Use sections to organize data into meaningful groups.


4.2 Testing.

Run the application with a screen reader to hear that
information is presented in a logical and meaningful order.


5.1 Option to display audio alerts

Provide an option to display a visual cue for all audio alerts.

5.1 Rationale.

Users may not be able to hear or distinguish sounds if they are
deaf or hard-of-hearing, work in noisy environments, or turn off
sounds to avoid disturbing others. In order for these users
respond to the audio alerts, those alerts must be presented
visually as well. Typical alerts might be the receipt of new
mail, beeps to indicate system errors, or sounds to indicate a
change in status.


5.1 Techniques.

The following techniques can be used to provide visual cues for
audio information.

  * System alerts are signaled to a deaf or hard-of-hearing user
    with SoundSentry feature in the Windows operating systems.
    This provides a generic visual indicator when the software
    makes a noise. SoundSentry works reasonably well in cases
    where the sound is just a generic beep that is warning the
    user or trying to attract his or her attention. For Windows
    and other operating systems, SoundSentry requires no special
    coding on the part of application developers.
  * However, SoundSentry is insufficient for applications that
    use different sounds to convey more complex information.
    Windows software can check the ShowSounds flag by calling
    the SystemParametersInfo function with the SPI_GETSHOWSOUNDS
    value, and if set present visual equivalents of all audio
    information.
  * Flash the title bar of the window which is receiving the
    alert. For Windows software, this can be done using the
    FlashWindow function. If the window is not visible, flash
    the application button on the taskbar to indicate the alert.
  * Display a message box for the alert.
  * Display a status indicator on the notification area of the
    taskbar that flashes when initially displayed to attract the
    user's attention.
  * Place a text message in a status window.


5.1 Testing.

  * If the software has an option to set user preferences,
    verify there are options to show audio alerts visually.
  * For Windows applications, go to the Sound tab under
    Accessibility Options in the Windows Control Panel. Turn on
    SoundSentry. Verify that the system provides a visual
    warning for system audio alerts.
  * For Windows applications, go to the Sound tab under
    Accessibility Options in the Windows Control Panel. Turn on
    ShowSounds. Verify that the system provides a visual cue for
    information provided through auditory output within the
    software.


5.2 Visual display of information in audio format

Provide an option to display audio information in text format,
either as closed captioning, a pop-up window or other means, in
parallel and/or in synchrony with the audio content.

5.2 Rationale.

Users may not be able to hear or distinguish sounds if they are
deaf or hard-of-hearing, work in noisy environments, or turn off
sounds to avoid disturbing others.


5.2 Techniques.

  * Provide a transcript of the audio which can be displayed
    separately, not synchronized with the audio track.
  * Provide a pop-up text window for short audio information.


5.2 Testing.

Test the portion of the software which provides auditory output.
Verify the information in the audio is available as text which
is either shown in parallel or in synchrony with the audio.


5.3 Visual display of information in video format

If important information is provided in video format, then the
same information must be provided in an accessible format.

5.3 Rationale.

Users may not be able to hear or distinguish sounds in a video
if they are deaf or hard-of-hearing. If the information is
important, it will need to be provided in another format so that
the user can access the information.


5.3 Techniques.

  * Provide a transcript of the video which can be displayed
    separately, not synchronized with the audio track.
  * Provide a long description of the video.
  * Provide a synchronized description of the video.


5.3 Testing.

Test the portion of the software which provides video output.
Verify the information in the video is accessible with a text
description of the video.


5.4 Disable sounds and adjust volume

Provide an option to enable the user to disable sound and adjust
the volume.

5.4 Rationale.

Users may not be able to hear or distinguish sounds at certain
volumes, so they need the ability to adjust the volume.
Sometimes it may be necessary to disable sound to avoid
disturbing others.


5.4 Techniques.

  * Windows applications can check the SM_BEEP option using the
    GetSystemMetrics function. If this option is FALSE, users
    have chosen to turn off the standard system beep, and you
    can assume whether they want other sounds turned off as
    well.
  * Windows applications where sounds are played by calling
    PlaySound and specifying a registry-based sound event do not
    require additional work to meet this checkpoint. The user
    can turn off these sounds by changing the Sound options in
    the Control Panel.


5.4 Testing.

Verify your application's sounds respect the system sound
settings or that there are application options to adjust the
volume and turn off sounds (turn volume off).


6.1 Displaying text

Use system text drawing tools or provide text through an API
(application programming interface) supporting interaction with
assistive technology. The minimum information that must be
available to an assistive technology is text content, text input
caret location, and text attributes.

6.1 Rationale.

Screen readers attempt to infer what software is doing by
watching calls to drawing functions and remembering what text
and graphics have been drawn and where. Those utilities also
save attributes of the text such as font, size, color, and
style, to be reported to the user. They also watch information
being copied from one location to another and being erased or
overwritten by other text or graphics. The component in a screen
reader that does all this difficult work is called an off-screen
model (OSM). OSM's rely on being able to monitor normal Windows
drawing operations.


6.1 Techniques.

  * Draw text using the standard function calls, such as Windows
    ExtTextOut, which can be seen by screen readers.
  * Use standard functions to copy or erase text and graphics.
    For Windows these include BitBlt, PatBlt, and StretchBlt.
    You need to do this whether drawing is to a screen or to an
    off-screen bitmap, because utilities track the text and
    graphics from the time they are drawn until they are copied
    to the screen.
  * Avoid directly manipulating bitmaps. Some applications
    directly manipulate the memory associated with a device
    context, bypassing the Windows functions altogether. In
    these cases screen readers are not aware of the changes
    taking place.
  * Avoid directly modifying the screen. The Windows application
    programming interface (API) provides several means of
    manipulating bitmap or display pixels directly, such as
    DirectDraw, Display Control Interface (DCI), WinG, and the
    CreateDIBSection function.
  * If your application uses any of the non-standard techniques
    for performance, you should also use conventional methods
    when a screen reader is running. You can determine this by
    calling the SystemParametersInfo function with the
    SPI_GETSCREENREADER value.


6.1 Testing.

Run the software with a screen reader and verify that all text
in client windows can be spoken.


6.2 Using color to convey information

Ensure that all information conveyed with color is also conveyed
in the absence of color.

6.2 Rationale.

If the software conveys information by color alone, users who
cannot identify or distinguish colors will not be able to make
use of the information. For example, asking users to press the
red button is not useful if they can't distinguish the red
button from other buttons on the screen. The software needs to
provide another way of making the information available.


6.2 Techniques.

  * Provide a brief text description of the object.
  * Include a graphic/character such as an asterisk by the item
    to denote importance.
  * Use other attributes, such as bold and/or italic in addition
    to color to distinguish text.


6.2 Testing.

  * Save screen shots and print on a black and white printer.
    Verify that all information is still conveyed.
  * For Windows applications, test with a high contrast setting
    black on white or white on black.


6.3 High contrast support

Support systems settings for high contrast for all user
interface controls and client area content.

6.3 Rationale.

For many people, color is a matter of preference, but it is
critical for many users with visual impairments. Many people
require a reasonably high contrast between text and the
background to be able to read. They may even need a particular
scheme, such as white text on a black background, to prevent the
background from "bleeding" over and obscuring the foreground
text. Some people consider the default color scheme quite
legible but find that it causes eyestrain over longer periods of
time.


6.3 Techniques.

  * For Windows software, use only colors that the user can
    customize through the Accessibility Settings for High
    Contrast in the Control Panel or through the application's
    own view options. Call GetSysColors to identify the colors
    chosen through Control Panel.
  * Windows software can check for the high contrast setting by
    calling the SystemParametersInfo function with the
    SPI_GETHIGHCONTRAST value. Applications should query and
    support this value during initialization and when processing
    WM_COLORCHANGE messages.


6.3 Testing.

For Windows software, turn on the high contrast setting, and
check that your application respects that setting. For example,
if you choose the High Contrast scheme to be "High contrast #1"
(yellow on black) in Windows 98, most window text, including the
main (client, document) window, should be yellow on black. In
this example, title bars and menus have different colors. You
can check the colors of the "High Contrast #1" by choosing that
scheme in the Display settings dialog, Appearance page.


6.4 Inherit system settings for display

Inherit system settings for font, size, and color for all user
interface controls (menus, buttons, dialog boxes, etc.).

6.4 Rationale.

Some people like to fit a maximum amount of information onto a
single screen, but many users have difficulty reading small
text, seeing small objects, or targeting small objects with the
mouse. Therefore you should be flexible when sizing objects on
the screen.

Small fonts cause eye-strain and can make reading difficult or
impossible for many people who do not have disabilities. To
these users, small font sizes represent failed usability. Screen
elements with fixed sizes may also be too small on
high-resolution displays or exceed the screen size on small,
hand-held computers.

When a user specifies system text attributes, your application
must support those.


6.4 Techniques.

  * If the application uses standard dialog controls including
    menus, then the system font color and size settings will be
    respected.
  * Windows applications that draw their own screen elements
    should pick up the size settings that the user has selected
    in the Display settings of the Control Panel. For example, a
    private dialog box manager that draws custom dialog boxes
    should use the dialog box font that the user has selected
    for the rest of the system. The same principle applies for
    scroll bars, custom menus, and so on.


6.4 Testing.

Test the application with a scheme with non-standard fonts and
colors.


6.5 Zoom option

Provide a zoom function that allows the user to increase or
decrease magnification of client area content.

6.5 Rationale.

The size of text and graphics affects usability as well as
accessibility. Many individuals who do not consider themselves
to be disabled want to "view" a document or an application work
area in an enlarged font while not affecting the actual document
or work. For individuals with acknowledged visual impairments,
the ability to zoom the application work area to 150%, 200% or
greater may make the difference between being able to use the
application or not. The vast majority of individuals who need
this kind of access do not use screen magnifiers.


6.5 Techniques.

  * Provide a zoom option in the View menu to allow flexible
    choice of enlarged text. Compare with Microsoft Word or
    Lotus 123.
  * Zoom features scale everything in the document to a
    user-selected ratio. Use of the TrueType scalable font
    technology ensures that characters will remain clearly
    defined at almost any size.
  * Draft mode means providing an option to display all text in
    a single font and size. If possible, allow the user to
    choose the draft font and size. Use underlining or a similar
    form of highlighting to indicate text that should be drawn
    with special formatting, such as bold or italics. (Draft
    mode also improves performance when running on slow systems
    or with little free memory.)
  * Wrap to window options are helpful when displaying text
    documents. When the user chooses this option, the
    application should not break lines on the screen as they
    would appear on the printed page, but instead reflow each
    paragraph to fit the window.


6.5 Testing.

Test all magnifications of the Zoom option. Verify that the
document is not effected by changing the Zoom setting.


6.6 Turn off backgrounds

Provide the capability for users to turn off patterned
backgrounds behind text or graphics.

6.6 Rationale.

Text drawn over a patterned background will be illegible for
many users because it does not provide sufficient contrast
between the background and the text, and because the pattern
"bleeds" into the text. In order for them to read the
information on the screen, users need to be able to turn off the
background and revert to a solid color background.


6.6 Techniques.

  * Provide an option which enables users to turn off the
    background in the software.
  * Turn off the background in response to the High Contrast
    setting.
  * Provide sufficient contrast in the default background and
    the text. For example, do not use black text on a gray
    background.


6.6 Testing.

Verify that any patterned background can be replaced with a
solid background.


7.1 Adjust response time

If timed responses or timed instructions are used by the
software, provide an option to adjust the response time or allow
the instruction to persist. The response time should be
adjustable to at least 5 times the average response time.

7.1 Rationale.

Some users have difficulty reading or responding to information
if it is displayed briefly or requires a quick response time.
Some response delays may also be caused by the use of assistive
technology used to read the screen or in the use of tools which
magnify only a portion of the screen.


7.1 Techniques.

  * Provide an option which enables users to adjust response
    times or enables instructions to persist.
  * Do not have timed responses for important messages. Display
    the message until the user closes it.


7.1 Testing.

  * Verify that all timed responses can globally be caused to
    persist for at least 5 times the average response time.
  * Verify that important messages are displayed until dismissed
    or until the user has sufficient time to read them.


7.2 Disable screen updates or flashing

Provide an option to either slow down or disable rapid screen
updates or flashing.

7.2 Rationale.

Rapid screen updates can cause epileptic seizures in susceptible
individuals. This includes flashing text or graphics on and off
or repeatedly changing between different images on the screen.


7.2 Techniques.

  * Provide an option which enables users to slow down or
    disable screen flashing.
  * Windows software. Flash information at the caret blink rate
    which can be adjusted through the Control Panel. Query this
    setting by calling GetCaretBlinkTime.


7.2 Testing.

If the software has rapid screen updates or flashing, then
confirming that there are no such events after the option to
disable those features has been exercised.


8.1 Accessible formats for documentation

Provide documentation in an accessible format, such as ASCII
text or HTML.

8.1 Rationale.

Some users may not be able to access product documentation if it
is not in an accessible format.


8.1 Techniques.

  * Provide product documentation on-line in ASCII text or HTML
    format.
  * Include text descriptions of illustrations (graphics) in the
    documentation.
  * Provide documentation in an accessible format (braille,
    audio cassette) upon request from the user.


8.1 Testing.

Test HTML documentation with one of the test tools suggested in
the relevant sections of the Web Accessibility Checklist.


8.2 Document accessibility features

Provide clear and precise documentation on all accessibility
features.

8.2 Rationale.

People with disabilities cannot effectively use the software if
they cannot access information on how to use accessibility
features. This requirement and checkpoint 1.2 may seem
unnecessary, but software development targets non-disabled
users, and accessibility features may get forgotten when the
product documentation is prepared.


8.2 Techniques.

  * Provide accessibility documentation in the product help.
  * Include a keyword search and help topic item for
    accessibility and/or disability.
  * Include a section called "Accessibility" where all
    accessibility documentation is provided.


8.2 Testing.

  * Open the software documentation. Search on the words
    "accessibility" or "disability".
  * If the product provides "how to" instructions and pop-up
    help, verify they include instructions for performing the
    actions using the keyboard in addition to using the mouse.


Object Inspector

Object Inspector is an application provided by Microsoft as part
of the Software Development Kit (SDK) for Active Accessibility.
Inspector can be used to validate the aspects of accessibility
of software user interface elements which use Microsoft Active
Accessibility (MSAA) or standard windows controls. It supports
software written for the Windows 9x, Windows NT or Windows 2000
platforms. Object Inspector can be downloaded as part of the
Microsoft Active Accessibility SDK. There is no charge to
download and use the SDK.

Once the SDK has been installed, go to the Program Menu, select
Microsoft Active Accessibility SDK and then Inspect Objects.
When Object Inspector is loaded, it displays information about
the properties of an object as you select the object with the
keyboard or move the mouse over the object. If the software uses
Windows standard controls, or if the controls are non-standard
and MSAA has been implemented, Inspector will report the
information. If the software uses custom controls which are not
exposed through MSAA, the properties will be blank and that is a
failure for accessibility. The following properties may be
exposed by the application.
  * Name - a string used to identify, find or announce an object
    (e.g., text on a button or tab, prompt on an entry field)
  * Role - describes what kind of user interface element an
    object is (e.g., push button. radio button, check box, combo
    box, edit box, page tab).
  * State - describes an object's status at a moment in time
    (e.g., selected, focused, selectable, unavailable, checked,
    unchecked)
  * Value - represents information contained by the object. For
    example, the value for a link is the URL for the link, the
    value of an edit field is the text in contains (if any), and
    the value of a combobox is the selected item (if any).
  * Description - provides a textual description about an
    object's visual appearance.
  * Help - provides information that tells the user about an
    object's function. This is typically used for balloon style
    information (e.g. ToolTips).
  * KeyboardShortcut - describes a key or key combination that
    will activate a specified object.
  * DefaultAction - describes the object's primary method of
    manipulation.

The graphic below shows a screen shot of Object Inspector where
focus is on a button.

For a selectable control, the important properties are Name,
Role and State. The value of the Name property is "Yes" because
that is the button label. The Role property identifies the type
of control, which in this case is a push button. The value of
the State property is "Normal" because the button is not
selected.

Using Object Inspector to verify selectable controls (e.g.,
radio buttons, check boxes, push buttons)

Selectable controls are accessible if they meet the following
criteria when testing with Object Inspector.

If any of the following fields are blank, the software is not
accessible.

  * Name: The name associated with the control. For example, in
    Notes Mail, there is a checkbox to identify confidential
    memos. The value of the Name property should be IBM
    Confidential.
  * Role: The type of control (radio button, check box, push
    button).
  * State: The state should be one or more of the following as
    appropriate - checked, unchecked, default (to indicate
    default push button), normal, focused, focusable,
    unavailable.

Using Object Inspector to verify graphics

Graphics are accessible if they meet the following criteria when
testing with Object Inspector.

If any of the following fields are blank for important graphics,
the software is not accessible.

  * Name: Text which describes the graphic.
  * Role: The type of control (graphic, link).
  * State: The state should be one of the following as
    appropriate - focusable, selectable, focused.
  * Value: The value of the URL for graphic links.

Using Object Inspector to verify edit controls

The following fields must be present as indicated.

  * Name: The static label of the edit field.
  * Role: The type of control, "editable text."
  * State: The state should be one of the following as
    appropriate - focusable, selectable, focused.
  * Value: The text contained in the edit field.

Magnifier

Magnifier is a Windows tool which allows you to magnify a
portion of the screen which is then displayed in a separate
magnifier window. Magnifier tracks the focus so it can
automatically keep the active area in the magnifier window.

Magnifier is available from Microsoft as part of the Software
Development Kit (SDK) for Microsoft Active Accessibility. When
you install the SDK, Magnifier will also be installed. To run
Magnifier from the SDK, go to the Start menu and select
Programs, Microsoft Active Accessibility SDK and then Magnifier.
If you are running on Windows 98 or Windows 2000, you can also
load Magnifier by going to the Start menu and selecting
Programs, Accessories, Accessibility, and then Magnifier.

When you start Magnifier, verify the following options are
selected:

  * Follow mouse cursor
  * Follow keyboard focus
  * Follow text editing
  * Show magnifier

Microsoft Active Accessibility (MSAA)

MicrosoftrActive Accessibilityr is a developer technology that
improves the way programs and the operating system work with
assistive technology. Using Active Accessibility, software
developers can make their programs more compatible with
assistive technology, and assistive technology developers can
make more reliable and more robust tools. You can find out more
about MSAA by visiting
http://www.microsoft.com/enable/msaa/default.htm

Screen Readers

Someone who is blind requires a screen reader to use a computer.
A screen reader makes information on the screen available as
synthesized speech or a refreshable braille display. Screen
readers can translate text information or graphics which have
alternate text describing the images. The ability of the screen
reader to read the software depends on the software's use of
standard operating system controls or accessibility APIs such as
Microsoft Active Accessibility (MSAA) for the Windows
environment.

Henter-Joyce offers a free demonstration copy or a timed
evaluation copy of JAWS for Windowsr on their web site at
http://www.hj.com/. The free demo is fully functional for 40
minutes each time you start a new Windows session, and includes
the Eloquence for JFW speech synthesizer. The timed evaluation
copy is available for a nominal fee and runs for 60 days.

GW Micro offers a free demonstration copy of Window-Eyesr on
their web site at http://www.gwmicro.com/. The free demo is
fully functional for 30 minutes each time you start a new
Windows session. You have to restart Windows to continue to use
Window-Eyes for another 30 minutes.

 References and resources

  "EITACC Desktop Software standards":
    Electronic Information Technology Access Advisory
    (EITACC) Committee.
    trace.wisc.edu/docs/eitacc_desktop_software_standards/
    desktop_software_standards.htm

  "Requirements for Accessible Software Design":
    US Department of Education, version 1.1 March 6, 1997.
    ocfo.ed.gov/coninfo/clibrary/software.htm.

  "Java accessibility guidelines and checklist":
    IBM Special Needs Systems. This site contains detailed
    guidelines for the Java environment.

  "Windows accessibility guidelines":
    Microsoft. www.microsoft.com/enable/dev/guidelines.htm.
    This site contains detailed guidelines specific to the
    Microsoft Windows software environment.

  "Web accessibility guidelines and checklist":
    IBM Special Needs Systems. This site contains detailed
    guidelines for the Web and HTML.

  "Lotus Notes accessibility guidelines":
    IBM Special Needs Systems.This site contains detailed
    guidelines for accessible Lotus Notes applications.

  "What is Accessible Software":
    James W. Thatcher, Ph.D., IBM, 1997. The paper discusses
    problems encountered by computer users who have
    disabilities and what developers can do to make their
    software accessible.

  "Making the GUI Talk":
    Richard S. Schwerdtfeger, IBM, 1993.
    ftp.software.ibm.com/sns/sr-os2/sr2doc/guitalk.txt. This
    paper discusses "Off-Screen Model" technology and GUI
    Screen Readers.

  "Towards Accessible Human-Computer Interaction":
    Eric Bergman, Earl Johnson, Sun Microsytems 1995.
    www.sun.com/tech/access/updt.HCI.advance.html. This
    paper discusses accessible user interfaces.

----------
>From the web page
http://www.austin.ibm.com/sns/accessweb.html

Web accessibility

Follow this checklist to make your Web site accessible. This
list has been updated and includes some of the latest quick tips
and guidelines from the W3C Web Accessibility Initiative found
at www.w3.org/WAI.

Table of Contents:

Checklist for Web accessibility

Rationale, Techniques, Testing

References and resources

Checklist for Web Accessibility

IBM Web Accessibility Checklist - Version 2.1

January 11, 2000


Rationale, Techniques and Testing

1. Images and animations

Use the alt=3D"text" attribute to provide text equivalents for
visuals. Use alt=3D"" for visuals that do not convey important
information or convey redundant information.

1. Rationale

Text browsers and screen readers cannot convey images to their
users. To compensate, it is important to associate alternative
text with all images, especially for active images, i.e., images
which are links or buttons. The alternative text should be
meaningful, like "home page" or "search" or "products." When
images are not links, use alternative text carefully. A person
having to listen to a page cannot ignore text the way a person
viewing the page can ignore an image. If images are not
important or if they are redundant, use alt=3D"", telling the text
browser to ignore the image.

The use of alternative text is not just for people who are
blind; alternative text is also used by voice recognition
software. Links which are images are not accessible to voice
recognition software unless the author has provided alt text for
the image. The user, navigating the Web with voice recognition,
can say "click home page" for the image whose alternative text
is "home page."


1. Techniques

Each IMG and AREA element must have an alt attribute. If the IMG
is not a link, and it is not important, use alt=3D"".

<IMG SRC=3D"http://www.ibm.com/solutions.gif" alt=3D"Solutions">

<IMG SRC=3D"http://www.ibm.com/filler.gif" alt=3D"">

Often navigation links are presented as images. The ideal
alternative text in this case is exactly the word or words
contained in the image. If the text on the graphic is
"solutions", then don't use "click here to go to the solutions
page" for the alt text. Use "solutions" just as it is seen in
the graphical browser.

Use alternative text for all AREA's in an image map. When the
mouse is passed over the client-side image map, these
alternative text entries will appear as text pop-ups.

<IMG src=3D"welcome.gif" alt=3D"areas in the library" usemap=3D"#map1">

<MAP name=3D"map1">

<AREA shape=3D"rect" coords=3D"0,0,30,30" href=3D"reference.html"

alt=3D"Reference">

<AREA shape=3D"rect" coords=3D"34,34,100,100" href=3D"media.html"

alt=3D"Media lab">

</MAP>

Image buttons need alternative text as in the following example.

<INPUT type=3D"image" name=3D"submit" src=3D"button.gif" alt=3D"submit">=



1. Testing


* The alternative text for each image is displayed as a text
pop-up when the mouse is held over the image. If an image is
important and no text pop-up appears, the image needs
alternative text. Unimportant or redundant images should be
tagged with alt=3D"" and nothing will pop-up when the mouse is
held over the image.


* If you turn off images in your browser each image will be
replaced with its alternative text. This is a good testing
technique for a quick text view of a page. It will be obvious
which graphics are not labeled. Microsoft Internet Explorer 5
works best for this test.


* When you view a page with IBM Home Page Reader, all the links
are in the Links List down the left. Make sure the text for each
link is meaningful and succint. If you see links in square
brackets with the word "Link" or "Map" ([Link:
http://www.ibm.com] or [Map: http://www.ibm.com/sns]), these
image links lack alternative text. HPR has inserted some part of
the URL because the alternative text is missing.


* Test the site with Bobby. Bobby will list all the images that
lack alternative text.


2. Image Maps

Use client-side image maps to provide accessible text for image
map hot spots. If you use server-side maps, provide equivalent
text links.

2. Rationale

Server-side image maps are not accessible to anyone using a text
browser or a browser with images turned off.

Client-side image maps are accessible to text browsers when the
alternative text is supplied for the map image and for each area
of the map. Refer to Checkpoint 1.


2. Techniques

If you must use a server-side map, then include a list of
equivalent text links, one for each URL that can be activated

through the map. For example, a map of the United States as a
server-side map would need a list of the individual states or
other alternative method of choosing a state. You could put link
text that said, "choose the state" next to the map. The
important thing is that the equivalent links be as convenient as
the server-side map for the user.

Use client-side image maps with alt text.

<map name=3D"top_nav2">

<area shape=3D"rect" coords=3D"0,19,139,38" href=3D"guestbook.html"
 alt=3D"Feedback">

<area shape=3D"rect" coords=3D"0,0,139,18" href=3D"sponsors.html" alt=3D=
"Sponsors">

</map>

Server-side Image Maps

Provide a list of text links when using a server-side image map.
The list of text links would be phrases representing the
clickable regions on the image.

For Example: If you had an image of a world map, where each
country boundry region was a hyperlink, you would also need to
list each of the countries as hypertext links.

Austria | Australia | etc.
Belgium | Belieze | etc.
USA | etc.


2. Testing

  * Home Page Reader will indicate a server-side map like this:
    "[Server Side Map: Sports]" (from the Washington Post). If
    there is a server side map, the equivalent text links must
    be present. Image areas of client-side maps that don't have
    alternative text show up like this: [Map: subst/home/home].
  * Test the site with Bobby. If you have a server-side map,
    that accessibility error will be the first Priority 1 item,
    "Provide redundant text links for all server-side image map
    hot-spots. (N instances)" in the Bobby report. Map areas
    without alternative text show up in the list of images
    without alternative text.


3. Graphs and Charts

Summarize the content of each graph and chart or use the
longdesc attribute to link to the description or data.

3. Rationale

A chart or graph is essentially an image with detailed
information. Text browsers and screen readers cannot convey
images to their users, so you need to provide a text equivalent
of the graphical information.


3. Techniques

Use one of the following three techniques for this checkpoint.
All three are illustrated in the example that follows.

  * Include the description in the flowed text.
  * Use a "D-Link" with a URL containing the description.
  * Use the long description attribute, longdesc=3D"longd.html"

D

This chart shows the percentage of cars and trucks out of the
total vehicles passing through a toll booth in one hour.
Seventy-five percent of the vehicles were cars; twenty-five
percent of the vehicles were trucks.

<IMG WIDTH=3D400 HEIGHT=3D263 SRC=3D"piechart.gif"

           longdesc=3D"longdexample.html" alt=3D"Of the vehicles passing=
 through a toll booth

           in one hour 75% of total vehicles were cars, and 25%
were trucks.">


3. Testing

All images should have alternative text per Checkpoint 1. The
only way to check for descriptions is to view all pages or check
the list of images that your authoring tool provides. Make sure
charts and graphs are described in line, through a D link, or
with a longdesc attribute on the image.


4. Multimedia

Provide captions or transcripts of important audio content.
Provide text or audio descriptions of important video content.

4. Rationale

For those who are deaf, or hard of hearing, audio content is not
accessible. Videos without descriptions are not accessible to
the blind. In both cases the information needs to be provided in
an alternative format. Important information contained in audio
or video also needs to be available in text.


4. Techniques

A transcript is a word-for-word textual version of the audio.
The user should be given the choice of reading the transcript or
listening to the audio.

The "description" is longer and more significant than the
"transcript". The "audio description" needs to be available in
text form. The video description should be available in both
text and audio form. The description can be both subjective and
artistic, depending on the intentions of the author. This
information is generally available at the beginning of the
creation process and should be retained and made available on
the Web along with the clip.

It may not be necessary to describe "earcons" or "soundcons"
(audio clips) that are associated with bullets, headrules,
backgrounds, etc. unless the author feels it is important to
capture that information and provide it to the user.

See the CPB/WGBH National Center for Accessible Media (NCAM) Web
site for examples.

The descriptions and transcripts can be on the same page, on a
separate page, or on a page with a listing of the descriptions
of all significant clips on that site. The current convention is
to place a hyperlink to the transcript and description near the
clip itself.


4. Testing

Manually search for all audio and video objects. Check that text
equivalents are provided for important video and audio.


5. Scripts, Applets, and Plug-ins

Where possible, provide alternate content for scripts, applets,
and plug-ins so important information is not lost when those
features are unsupported or turned off.

5. Rationale

None of the text browsers, like IBM Home Page Reader or Lynx,
support JavaScript. When you require script execution, users of
those browsers will not be able to access your page. JavaScript
that changes highlighting or fonts is not an issue for
accessibility unless the information conveyed in the mouseover
is necessary to understand or navigate the Web site.

Applets and Plug-ins are not currently supported by the text
browsers or IBM Home Page Reader. However, you can make applets
directly accessible; refer to IBM's Java accessibility for more
information.


5. Techniques

JavaScript

Try to ensure that links that trigger scripts work when scripts
are turned off or not supported. For example, do not use
"javascript:" as the link target. If it is not possible to make
the page usable without scripts, you may be able to provide a
text equivalent with the NOSCRIPT element, use a server-side
script instead of a client-side script, or provide an
alternative accessible page.

Avoid creating content on the client through scripting. If a
user's browser does not handle scripts, no content will be
generated or displayed. Refer to the W3C documentation on
JavaScript for further details.

Applets and Plug-Ins

Provide alt text for Applets.
<applet code=3D"gravity.class" width=3D"200" height=3D"250" alt=3D"Java
gravity applet">...</applet>

If the OBJECT element is used, provide a text equivalent in the
content of the element.
<OBJECT classid=3D"java:gravity:class" width=3D"200"
height=3D"250">When gravity acts on an object, the weight...
</OBJECT>


5. Testing

Test your page with applets and scripts turned off in your
browser.
  * In Netscape go to Edit/Preferences/Advanced to turn off
    JavaScript and Java Applets.
  * With Internet Explorer choose Tools/Internet
    Options/Security to turn off scripts and applets.

If you have not used the NOSCRIPT element or provided a text
equivalent for JavaScript, the page will be broken or unusable.
If you did not make the applet directly accessible or provide
alt text, you will see no content where the applet should appear.


6. Forms

Associate labels with form elements.

6. Rationale

For general ease of use it is important for the labels, like
"Last Name," to be clearly and programmatically linked with the
corresponding form element, in this case an text input field.
When the labels are explicitly associated with the form elements
through HTML markup, assistive technologies can present the Web
author's intention to a person who is blind.


6. Techniques

Some form controls, such as submit buttons, automatically have
labels associated with them, but most do not (text fields,
checkboxes and radio buttons, and menus). If a label is
immediately to the left of a form control or immediately above
the element, then assistive technology will usually be able to
convey the intent as conveyed by proximity. HTML 4 provides
specific markup, the LABEL element, to connect the form element
and its label.

Here is a form with two input fields and two buttons.

Name
<___>
Address
<___>

<Submit><Reset>

 Here is the HTML for this form in which the input fields are
programmatically connected with the corresponding label.

<form action=3D"mailto:thatch@us.ibm.com">

<LABEL for=3D"Name1">

  Name

</LABEL><br>

  <input name=3D"Name" id=3D"Name1" size=3D30> <br>

<LABEL for=3D"Address">

  Address

</LABEL><br>

  <input name=3D"Address" id=3D"Address" size=3D45> <br>

<input type=3D"submit" value=3D"Submit">

<input type=3D"reset" value=3D"Reset"> <br>

</form>

The following markup for the LABEL element groups the form
control with the label and is equivalent to that above.

<LABEL>

  Name<br>

  <input name=3D"Name" size=3D30>

</LABEL> <br>

<LABEL>

  Address<br>

  <input name=3D"Address" size=3D45>

</LABEL> <br>


6. Testing

Test your form using Home Page Reader's "Where Am I" command
(plus then 5). HPR will announce the label of a text input field.


7. Skip to main content.

Provide methods for skipping over navigation links to get to
main part of a page.

7. Rationale

When a navigation bar appears at the top of a page and/or down
the left side of the page, users who are reading the page with
speech synthesis will have to listen to all of those links
across the top and down the left for each page they visit at the
site before they get to the main content. However, users who are
sighted ignore the links and go right to the main content. The
purpose of this checkpoint is to fix this inequity.


7. Techniques

Here are the methods that you can use to allow users to quickly
bypass groups of links (navigation bars, table of contents,
etc.) to get to other portions of a page.

  * The cleanest method is illustrated on the IBM Special Needs
    Systems pages. At the top of the page is a link attached to
    an unimportant image, and the target of that link is the
    beginning of the main content. The alternative text for the
    image is "skip navigation links." So a person a using speech
    synthesis can activate the link associated with the alt text
    and skip down to the main content of the page.

<a href=3D"#navskip"><img src=3D"blank.gif" alt=3D"skip to main content"=
></a>

...

    <a name=3D"navskip"></a><h1> The main content...</h1>
    The target can easily be part of a template, as it does not
    have to be associated with text content.
  * A simple alternative to the first technique is to display
    the "skip navigation" link at the top of the page. This is
    illustrated at the American Council of the Blind (ACB) site.
    ACB was the first to use this technique.
  * If all navigation links are in client-side image maps with
    good alternative text on the areas then by default, IBM Home
    Page Reader will skip the areas, with an announcement like
    "Map, skipping 10 items." Of course the user can stop and
    step through the map areas. So using Home Page Reader, image
    map areas are skipped automatically.
  * You may have several sections of main content. A variation
    on the first technique above is to have a series of links
    attached to unimportant graphics, for example, "skip to
    headlines," "skip to sports," and "skip to business."
  * Use headings. If the main content is under the first
    heading, then the assistive technology can jump to that
    heading.


7. Testing

Test the site with IBM Home Page Reader. Try to get to main
content. If your site is using templates, ensure that the
templates implement the first of the techniques above.


8. Frames

Provide a title for each frame so that users can track frames by
title.

8. Rationale

When people who use text browsers like Home Page Reader and Lynx
visit a FRAMESET page, they must choose which Frame to open. The
choice is given with a list of the Frames. If Web authors
provide meaningful information in their markup, then those users
can make intelligent choices.


8. Techniques

There are two parts to the technique for addressing the frame
navigation problem. First there should be meaningful titles on
each Frame page (the src of each FRAME element). The second part
of a solution is to provide a meaningful name attribute and
title attribute for each FRAME element.

 <HTML>

    <HEAD>

      <TITLE>A simple frameset document</TITLE>

    </HEAD>

    <FRAMESET cols=3D"10%, 90%" title=3D"Our library of electronic docum=
ents">

      <FRAME src=3D"logo.html" title=3D"Company logo frame" name=3D"comp=
any logo">

      <FRAME src=3D"navigation.html" title=3D"navigation frame" name=3D"=
navigation">

      <FRAME src=3D"maincontent.html" title=3D"Company main content" nam=
e=3D"main contents">

<NOFRAMES>

        <A href=3D"companyindex.html" title=3D"Company index">

             Select to go an index of the Company's Web site.</A>

      <NOFRAMES>

    </FRAMESET>

As an example of frame navigation, here is what Lynx presents
for the five frames of one page; Lynx displays the frames names
using the NAME attribute on each FRAME element.

 FRAME: company logo

 FRAME: navigation

 FRAME: main contents

Home Page Reader opens each frame page and inserts the page
title, if it is available. If the title is not available, the
name attribute is listed.

[Frame 1 (company logo): Untitled]

[Frame 2: Navigation for the company Web site]

[Frame 3: Main contents for company Web site]

In this example, Frame 2 and 3 get there information from the
TITLE element from navigation.html and maincontent.html. Frame 1
has taken the name attribute of the FRAME element because
logo.html is untitled.


8. Testing

Check that every FRAME element has a meaningful name and title
attribute. Check that each frame page has a meaningful title in
the TITLE element.


9. Tables

Where appropriate, use the CAPTION element and/or the summary
attribute for tabular data. Use the headers attribute on cells.

9. Rationale

If you have normal vision, you can quickly scan through a table
and get a general idea about the data it presents. The purpose
of the CAPTION element and the summary attribute on the TABLE
element is to provide the same kind of information to a person
who is blind or has low vision.

If you can see a TV listing (table), you have the ability to
scan up a column and across a row to find the station and time
of a program. If you cannot see the table, but are listening to
it with speech synthesis, it can be a daunting task to try to
find this simple information. The headers attribute provides one
solution to this problem.


9. Techniques.

The CAPTION element provides a technique for displaying a title
for a table. The summary attribute on the TABLE element provides
a description of the contents of the table. Here is a sample
table:

Cups of coffee consumed by each Senator
                                                        
              Name      Cups   Type of Coffee   Sugar?  
                                                        
            T. Sexton   10     Espresso         No      
                                                        
            J. Dinnen   5      Decaf            Yes     
                                                        

The markup for this table follows.

<TABLE border=3D"1"

         summary=3D"This table gives the number of cups

                  of coffee consumed by each senator, the type

                  of coffee (decaf or regular), and whether

                  taken with sugar.">

  <CAPTION>Cups of coffee consumed by each Senator</CAPTION>

  <TR>

     <TH id=3D"t1">Name</TH>

     <TH id=3D"t2">Cups</TH>

     <TH id=3D"t3">Type of Coffee</TH>

     <TH id=3D"t4">Sugar?</TH>

  </TR>

  <TR>

     <TD headers=3D"t1">T. Sexton</TD>

     <TD headers=3D"t2">10</TD>

     <TD headers=3D"t3">Espresso</TD>

     <TD headers=3D"t4">No</TD>

  </TR>

  <TR>

     <TD headers=3D"t1">J. Dinnen</TD>

     <TD headers=3D"t2">5</TD>

     <TD headers=3D"t3">Decaf</TD>

     <TD headers=3D"t4">Yes</TD>

  </TR>

  </TABLE>

The content of the CAPTION element is displayed, but the summary
is not. An assistive technology browser, like Home Page Reader,
will offer that summary to its user. This provides the kind of
information a sighted user can obtain by looking at the table.

The TH element creates a heading style in the rendered table.
The heading cell has an ID attribute. In the data cells, the
headers attribute specifies the data to be taken as headers for
the cell. For example, the cell with "10" in it has headers=3D"t2"
and the cell with id=3D"t2" has "Cups" in it. So the header for
"10" is "Cups."

The headers attribution can be more complicated. For example the
same table could contain the following markup

 <TR>

     <TD headers=3D"t1", id=3D"name1">T. Sexton</TD>

     <TD headers=3D"name1 t2">10</TD></TR>

In this case the heading for "10" would be "T. Sexton Cups"
since the contents of name1 is "T. Sexton", and the contents of
t2 is "cups".


9. Testing

Check the web site for tabular data, and make sure that those
tables meet this checkpoint. Using Bobby, you can obtain a list
of the TABLE elements in the site. With IBM Home Page Reader,
the table summary is announced in response to the whereAmI
request. Headers are announced as the cells are traversed.


10. Correct Markup

Do not use structural markup, such as headings and lists, for
visual presentation effects.

10. Rationale

Using markup improperly hinders accessibility. Misusing markup
for a presentation effect, such as using a table for layout or a
header to change the font size, makes it difficult for users
with specialized software to understand the organization of the
page or to navigate through it. Using presentation markup rather
than structural markup to convey structure makes it difficult to
render a page intelligibly to other devices. For example, you
should not construct what looks like a table of data with an
HTML PRE element.

You may be tempted to use or misuse constructs that achieve a
desired formatting effect on older browsers, but be aware that
these practices cause accessibility problems. Consider whether
the formatting effect is so critical as to warrant making the
document inaccessible to some users.

At the other extreme,you must not sacrifice appropriate markup
because a certain browser or assistive technology does not
process it correctly. For example, it is appropriate to use the
TABLE element in HTML to mark up tabular information even though
some older screen readers may not handle side-by-side text
correctly (refer to checkpoint 9). Using TABLE correctly makes
it possible for software to render tables other than as
two-dimensional grids.


10. Techniques

Use header elements to convey logical structure and use them
according to specification. For example, in HTML, use H2 to
indicate a subsection of H1. Do not use headers for bold or font
effects.

Use list elements to convey lists of information properly. For
example, in HTML, nest OL, UL, and DL lists as specified. Do not
use list elements for visual indentation formatting effects.

Use quote elements for quotations. For example, in HTML, use the
Q and BLOCKQUOTE elements to markup short and longer quotations,
respectively. Do not use quotation markup for visual indentation.

Refer also to the Techniques for Web Content Accessibility
Guidelines section on "Document structure and metadata"
http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#document


10. Testing

Check your HTML markup. Are you following the proper structural
coding?


11. Cascading Style Sheets

Control presentation and layout with style sheets (CSS) rather
than presentation elements and attributes.

11. Rationale

>From the W3C Web Accessibility Content Guidelines Guideline 3:

Cascading Style Sheets describe how documents are presented on
screens, in print, or perhaps how they are pronounced or
brailled. Style Sheets is a elegantly designed yet simple
mechanism for adding style (e.g. fonts, colors, spacing) to Web
documents. By attaching style sheets to structured (e.g. HTML)
documents on the Web, authors and users can influence the
presentation of documents without sacrificing
device-independence or adding new HTML tags. CSS is one of the
greatest hopes for separation of presentation from content.

The Web is the ultimate cross-platform system, and your content
will be presented on such a huge variety of devices that source
pages should specify the meaning of the information and leave
presentation details to a merger (or "cascade") of
site-specified style sheets and user's preferences. If the
introduction of WebTV or "accessibility" or audio browsers broke
your pages, you will appreciate the ability to introduce new
page designs by creating a single style sheet file rather than
by modifying thousands of content pages.

Style sheets have been an activity since the World Wide Web
Consortium (W3C) was founded and have resulted in the
development of CSS1. For background and tutorial information on
style sheets, see the Web style sheets resource page.


11. Techniques

Use style sheets to control layout and presentation. For
example, use the CSS 'font' property instead of the HTML FONT
element to control font styles.

Refer also to CSS2 ( Cascading Style Sheets), which allows
content developers to duplicate almost every HTML 4.0
presentation feature and offer more power with less cost.
However, until most users have browsers that support style
sheets, not every presentation idiom may be expressed
satisfactorily with style sheets.

In the W3C Techniques for Web Content Accessibility Guidelines
CSS section, it is shown how style sheets may be used to create
accessible pages. Examples are also provided of how to use HTML
4.0 features (e.g., tables, bitmap text) more accessibly when
they must be used.


11. Testing

There is no true test for style sheets.


12. Hypertext Links

Use descriptive link text, not just "click here." Ensure that
each link makes sense when it is read out of context.

12. Rationale

Users of the Web who are blind will often scan through a list of
links in a document to understand the layout and options on the
page. Links that say "go" or "click here" do not make sense out
of context.


12. Techniques

Link text should be descriptive, more than "click" or "here",
without being so wordy that it interferes with efficient
browsing. Several browsers for voice navigation, as well as
screen readers, now list the links separately. All links should
make sense out of context.

Instead of writing,

To return to checkpoint click here.

Make "return to checkpoint" the link.


12. Testing

Screen Readers such as Jaws For Windows (JFW) and Window-Eyes
provide lists of links. Home Page Reader also has a links list.
Authoring tools often provide links lists. With any of these
methods, examine the links to be sure that they make sense and
are not too verbose.


Appendix

The appendix expands on some of the earlier instruction on
testing using IBM Home Page Reader, Microsoft Internet Explorer
5.0, and Bobby.

Microsoft Internet Explorer 5.0

You can obtain Internet Explorer 5.0 from the Microsoft's IE5
site. To turn off images,

  * Select Tools - Internet Options - Advanced.
  * Select "Always expand alternative text for images."
  * In the multimedia section deselect "Show pictures."

IBM Home Page Reader

IBM Home Page Reader is designed for people who are blind or
have severely low vision. This explanation is for people with
normal sight who want to test Web sites for accessibility. It is
not necessary for such a person to learn all the key
combinations, settings and navigation strategies if you can see
the HPR display and the Netscape windows.

A full function thirty day trial version of IBM Home Page Reader
(HPR) is available at the IBM Special Needs Systems web site.
The Home Page Reader product can be purchased at ShopIBM. People
who are employed by IBM can find Home Page Reader on the IBM
internal Special Needs web site.

The Stop button stops speech. Listen to the page with Play. If
the speed of the speech is too slow, you can always increase it
using the Rate slider on the left of the control window.

The fundamental test for accessibility is whether all the
information available visually in Netscape or Internet Explorer
is also available in text in HPR. You can listen to each page
and hear what a blind person hears. When alternative text on
images is missing or cumbersome, it will be obvious. In its
default settings, HPR speaks all active elements, including
links and control elements, in a female voice.

Instead of listening to every word on the page, you can examine
the HPR text view (the Contents window). HPR provides
information which will help you to make the page easier for all
to use while you make it more accessible. Information from the
page which is not displayed in the Netscape or Internet Explorer
graphical view is enclosed in square brackets. Meta-information
added by Home Page Reader is enclosed in parentheses.

The Location Text Field

Enter a URL for a page to be spoken. The URL of the current page
is displayed here.

The Links List

The Links List window lists all the links in the current page.
Double click on a link to follow it. As soon as you load a page
HPR starts talking. As you listen to the page, the current link
is highlighted and spoken in a female voice. The items in square
brackets are image links. The text in each case is the
alternative text and should be both meaningful and succinct.

The History List

If you resize (enlarge) the main window on the right, a history
list will be displayed in the top right corner. This is the list
of previously visited pages. The current page is highlighted. To
return to any page, just double click the page you want.

The Contents Text Area

The text version of the current page is displayed here. As the
page is spoken, the current paragraph (item)  is highlighted and
then words are "unhighlighted" after each is spoken.

As you move the caret around the contents window, lines, words,
or characters will be spoken. As active elements are spoken, the
corresponding link in the Links List is highlighted.

Just as in the Links List, text that is not rendered in the
graphical browser is placed inside square brackets. This is
alternative text for images and image links. In the case of
links, if there is no alternative text, then some substring of
the target URL is placed in the brackets instead.

The text in parentheses is called "meta text."  It alerts the
reader to the beginning of forms and select menus. The HPR
search function includes the ability to search for meta text.

The Control Area

Several controls have already been mentioned (Play, Stop, and
Rate).

Back opens the previous page in the history list. Next opens the
next page. Reload reloads the current page.

Bookmark opens the HPR bookmark page. Add Bookmark places the
current URL at the bottom of the bookmark page.

When Auto Sync is checked, the page loaded in HPR will be
displayed in Netscape. Conversely, if you load a page in
Netscape it will be spoken by HPR.

When Auto Sync is not checked, you can use the Speak Browser
button to have the Netscape page rendered in HPR and the Show
HPR button to have the HPR page displayed in Netscape.

The Volume slider changes volume.

Speaking an item at a time

You can step through the entire page using the the next item
key, 6 on the numeric keypad. Previous item is 4, and current
item is 5.

Saving the current page

You may want to save the text view of the page to a file. Bring
up the Text Entry Dialog with Plus then Dot on the numeric
keypad. Type > (for redirect) and a file designation, for
example,

>C:\docs\mysite.txt

This will save the file as a text file (mysite.txt in this
case). If the extension is .htm, the file will be saved as an
html file.

Searching

To search in the text view, bring up the input dialog with Plus
then Dot. Enter a forward slash and the text, e.g.,

/New Releases

HPR will search for "New Releases" in the text content window.
The search is not case sensitive. You can continue searching
with the chord, enter with 6, on the numeric keypad.  Enter with
4 searches backwards.

Bobby

Bobby is a tool for analyzing web pages for accessibility and
conformity to HTML specifications. It has been developed by the
Center for Applied Special Technology

Bobby comes in two flavors. With the Web version of Bobby you
insert a URL for an internet page, and obtain a Bobby report
on-line.

Alternatively you can download Bobby and use the tool on web
pages under development.

References and resources

  "IBM Home Page Reader:
    IBM Special Needs Systems.
    http://www.austin.ibm.com/sns/hpr.html. IBM's talking
    Web browser for blind and visually impaired users.

  "Java accessibility guidelines and checklist":
    IBM Special Needs Systems.
    www.austin.ibm.com/sns/accessjava.html. This site
    contains detail guidelines for the Java environment.

  "Software accessibility guidelines":
    IBM Special Needs Systems.
    www.austin.ibm.com/sns/accesssoftware.html. This site
    contains general software guidelines.

  "Towards Accessible Human-Computer Interaction":
    Eric Bergman, Earl Johnson, Sun Microsystems, 1995.
    www.sun.com/tech/access/updt.HCI.advance.html. This
    paper discusses accessible user interfaces.

  "Experiences Implementing Web Accessibility Guidelines in
  IBM":
    Phill Jenkins, IBM, 1997.
    www.austin.ibm.com/sns/phillj.htm. This paper covers
    disabilities issues and older general accessibility
    guidelines.

  "Web Content Accessibility Guidelines":
    World Wide Web Consortium (W3C), 1999.
    http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html.
    These guidelines cover the responsibilities of the
    content author.

  "List of Checkpoints for the Web Content Accessibility
  Guidelines":
    World Wide Web Consortium (W3C), 1999.
    www.w3.org/TR/WAI-WEBCONTENT/full-checklist.html. A
    checklist for Web content developers. Each checkpoint in
    the guidelines appears in this list, organized by
    priority and concept.

  "Techniques for Web Content Accessibility Guidelines":
    World Wide Web Consortium (W3C), 1999.
    www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth-tech.html.
    This document includes techniques and examples that HTML
    and CSS authors may use to implement the guidelines and
    meet the checkpoints described in "Web Content
    Accessibility Guidelines".

  "User Agent Accessibility Guidelines":
    World Wide Web Consortium (W3C), 1999.
    www.w3.org/TR/WD-WAI-USERAGENT/. These guidelines cover
    the responsibilities of the browsers.

  "Authoring Tools Accessibility Guidelines":
    World Wide Web Consortium (W3C), 1999.
    www.w3.org/TR/WD-WAI-AUTOOLS/. This document provides
    guidelines to Web authoring tool manufacturers or
    developers. The purpose of this document is two-fold: to
    assist developers in designing authoring tools that
    generate accessible Web content and to assist developers
    in creating an accessible authoring tool user interface.

----------
>From the web page
http://www.austin.ibm.com/sns/accessjava.html

Java tm accessibility


IBM Special Needs Systems and Sun Microsystems' accessibility
group have combined efforts to design and build next-generation
accessibility into Java. IBM issued a press release about
bringing the power of Java to users with disabilities. Learn
more about the accessibility issues being addressed and read the
accessibility article featured on IBM's Java site. Read how IBM
is focusing on the Java platform for accessibility and how Java
can speak using the Self Voicing Kit (text-only SVK site), which
is IBM's solution to bring cross-platform accessibility to
mainstream computing. 


Table of contents:

Checklist for accessible Java applications
Java accessibility guidelines
References and resources. 


 Checklist for accessible Java applications 

Follow this checklist to make your Java application accessible.
For anyone developing graphical Java applications it is important
that you follow this checklist. In the follow-on guidelines
section, detailed examples are shown on how to write accessible
Java applications using the Java Foundation Classes (JFC/Swing)
and the Java Accessibility API. 


Java accessibility checklist - version 2.1
January 11, 2000

1
User interface components.

1.1
Use the Java Foundation Classes (JFC) / Swing components or
implement the Java Accessibility API. 

1.2
Follow the guidelines when extending the Java Foundation
Classes/Swing components. 
 
1.3
Follow the guidelines to implement the Java Accessibility API on
custom components. 
 
 
2
Essential programming practices.

2.1
Enable keyboard access (operable without the mouse).
 
2.2
Describe icons and graphics and set AccessibleDescriptions on all
components.
 
2.3
Set the focus.
 
2.4
Label components.
 
2.5
Be multi-threaded so an assistive technology can also run.
 
2.6
Name logical groups.
 
2.7
Provide a logical layout.

 
3
Documentation.

3.1
Provide documentation in an accessible format such as ASCII text
or HTML. 
 
3.2
Provide documentation on all accessibility features as part of
the regular product documentation. 
 
 
4
Verify accessibility.

4.1
Test for accessibility using "assistive technology" (i.e., IBM
Self Voicing Kit technology for Java available from
http://www.alphaWorks.ibm.com). 
 
 
  Java accessibility guidelines 

The "IBM Guidelines for Writing Accessible Applications Using
100% Pure Java" are available as a complete document. This is the
industry's first set of 100% Pure Java application development
guidelines for accessibility. A brief outline of the contents is
included here to give you an overview of the information: 

* 1.0 Executive Summary 

* 2.0 Introduction 
o 2.1 Disability Issues 
o 2.2 Why Java for Accessibility? 

* 3.0 Essential Accessibility Programming Practices. 
You will find a list of specific practices that are absolutely
essential in order to make your Java application usable by
persons who have disabilities. 

* 4.0 Java Foundation Classes (JFC) - A Foundation for
Accessibility 
This section discusses the huge advantages of using the JFC to
provide accessibility. 

* 5.0 Using JFC to Build Accessible Applications 
Read this section to find out specifics about using the JFC to
incorporate accessibility features in your applications. The
section includes the following topics: 
o Setting up the JFC Development Environment 
o Using the JFC Components unmodified 
o Enhancing JTextComponents 
o Changing Data Models and Cell Renderers 
o Creating new Components based on the JFC 
o Preparing for Future JFC Accessibility Features 

* 6.0 The Accessibility API 
This section defines the Accessibility API. If you don't use the
JFC, you can implement the Accessibility API to ensure that your
application is accessible. The API allows assistive technology
software to extract information from your components. Note: The
Accessibility API is now shipped with the JFC package and can be
found in the com.sun.java.accessibility package. It is scheduled
to be integrated into JDK 1.2 

* 8.0 Testing for Accessibility 
Includes a checklist on how to use the test tool features of
IBM's Self Voicing Kit (SVK) to test your application for
accessibility. 

* 9.0 Online Information and Help 
When developing documentation for your application in HTML please
follow the comprehensive Web accessibility guidelines. 

* 11.0 Appendix 
The appendix contains the suggested keyboard bindings and a list
of accessibility references. 


 References and resources 

"Software accessibility guidelines and checklist": 
IBM Special Needs Systems. This site contains the software
guidelines and a checklist. 

"Windows accessibility guidelines": 
Microsoft. www.microsoft.com/enable/dev/guidelines.htm. This site
contains detailed guidelines specific to the Microsoft Windows
software environment. 

"Web accessibility guidelines and checklist": 
IBM Special Needs Systems. This site contains detailed guidelines
for the Web and HTML. 

"Towards Accessible Human-Computer Interaction": 
Eric Bergman, Earl Johnson, Sun Microsystems, 1995.
www.sun.com/tech/access/updt.HCI.advance.html. This paper covers
accessible user interfaces. 

"Making the GUI Talk": 
Richard S. Schwerdtfeger, IBM.
ftp://ftp.software.ibm.com/sns/sr-os2/sr2doc/guitalk.txt
Off-Screen Model Technology and GUI Screen Readers 

"Accessibility Quick Reference Guide": 
Sun Microsystems. www.sun.com/tech/access/access.quick.ref.html. 

"Java Development Kit": 
Sun Microsystems. java.sun.com/products/jdk/. 

"Java Foundation Classes (JFC/Swing)": 
Sun Microsystems. java.sun.com/products/jfc/.

----------
>From the web page
http://www.austin.ibm.com/sns/accessnotes.html

Lotus Notes accessibility

These guidelines are provided to help make your Lotus Notes
applications accessible to everyone. Some features in Lotus
Notes 4.x are not accessible to people with disabilities (e.g.,
navigators, smart icons). It is important to follow these
guidelines to develop Notes applications which are accessible.

Table of Contents:

Checklist for accessible Lotus Notes applications

References and resources

Follow this checklist to make your Lotus Notes 4.x applications
accessible.

Please fill out all checklist items. Enter Y if the checklist
item is supported in the offering, N if not supported, and N/A
if not applicable to the offering. For all checklist items that
are not supported or not applicable, enter a brief explanation
in the comments section.

IBM Lotus Notes 4.x Accessibility Checklist - Version 2.1

January 11, 2000


  * 1.1 Navigator actions.

Provide alternate methods to accomplish actions available
through the graphical navigator. Make all navigator actions
available through the keyboard.

1.1 Rationale.

Navigators provide a graphical display of folders, views and
design elements to make it easier for most users to find
information. However, you cannot access the navigator without
the use of a mouse and the graphical display of information is
inaccessible to assistive technologies like screen readers. In
order to make navigators accessible to those who are using the
keyboard or a screen reader, it is important to provide an
alternative method to accomplish the same functions. This is
especially true for full screen navigators which do not enable
the user to use the View-Go To function to open the Notes
navigation pane to display the list of views.


1.1 Techniques.


* When a navigator is used to simplify the list of views
available to the user, the views listed in the navigator must
also be listed in the View menu. Open the View Properties. Under
the Options tab, select the option "Show in View menu". The name
of the view should be consistent with the name of the action on
the navigator.


* When a navigator includes actions, such as creating documents
or performing specific actions, there should be a corresponding
action in the Actions menu with equivalent function. If the
navigator has an option "Submit a badge request", there should
be an action "Submit a badge request" in the Actions menu with
the same function.

1.1 Testing.


* Open each action on the navigator and make a note of the
function for each action.


* Remove the mouse.


* Using only the keyboard, verify there are equivalent actions
available for all navigator actions.


* If the action opens a view, verify there is a view with the
same name listed in the View menu.


* If the action creates a document, verify there is an action in
the Actions menu with the same name or the document is listed in
the Create menu.


* If the action opens another database, verify there is an
action in the Actions menu with the same name as the Navigator
action.


1.2 Navigator backgrounds.

Do not embed the hotspot text or link text into navigator
bitmaps.

1.2 Rationale

Most navigators include graphic backgrounds as well as a
combination of graphic and text hotspots. When the text for the
hotspots is embedded in the graphic background, that information
is not available to screen readers. The screen reader cannot
access information about the links, even if the user tries to
use the mouse to explore the navigator. In order to make the
text on the background accessible, it cannot be included as part
of the bitmap for the background.


1.2 Techniques

When you add the text boxes after you have pasted the graphic
background, it makes the design more accessible and enables you
to reuse the graphic for more than one navigator. Follow the
steps below to create a navigator without embedded text.


* In your graphics program, copy the graphic background you want
to use for your navigator to the clipboard.


* Open the database where the background will be added and
choose View-Design.


* In the navigation pane, click on Design-Navigators.


* Select the navigator you are editing and choose Create-Graphic
Background.


* Create the text boxes for your hotspots and place them on top
of the graphic background.


1.2 Testing


* The only method to test Navigators is to run the database with
a screen reader. Start the screen reader and then start Notes.


* If the Navigator is not full screen:


* F6 to switch to the Navigator pane.


* Using the screen reader's "Say All" command, read the
navigator.


* Using the screen reader's cursor commands, move through the
navigator and hotspots to be sure they are read. If they are not
read or if the screen reader says "blank", the text has been
embedded in the graphic and is not accessible.


* If the Navigator is full screen:


* Using the screen reader's "Say All" command, read the

 navigator.
    * Using the screen reader's cursor commands, move through
      the navigator and the hotspots to be sure they are read.
      If they are not read or if the screen reader says "blank",
      the text has been embedded in the graphic and is not
      accessible.


2.1 Include action buttons in menu

Include all action buttons in the Actions menu.

2.1 Rationale

Each form and view has its own action bar to display the actions
available for use with that part of the application. The action
bar cannot be accessed through the keyboard. If the actions are
only available on the action bar, many users will not be able to
use the application.


2.1 Techniques

You can make the actions on the action bar accessible by
including them as choices on the Actions menu. When you create
the action, select the option "Include action in Action menu".
Choices are displayed in the Actions menu in alphabetical order.
If you have a large number of actions this may not be the most
effective way to select frequently used actions. Someone using
the keyboard and a screen reader to search the list, must go
down the list in sequential order. If the most common action is
the last one in the list, this can be tedious. You can force the
names to appear in a different order by numbering the frequently
used actions so they appear at the top of the list.

It is also helpful to define meaningful accelerator keys for
your actions. Notes will assign an accelerator key to any action
in the Actions menu, but it may not be meaningful or easy to
remember. You can force the use of a specific accelerator key by
typing an underscore before the letter you want to assign as the
accelerator. The underline is not displayed on the action bar.

For example, to make S the accelerator for the Submit request
action, type _Submit request


2.1 Testing

  * Remove the mouse.
  * Using only the keyboard, verify there are choices in the
    Actions menu for all buttons on the action bar.


2.2 Provide text labels for buttons

Provide text labels for all buttons. Do not create buttons
without labels or buttons which only use graphical icons to
describe the function of the button.

2.2 Rationale

Screen readers rely on the text label on buttons to describe the
purpose of the button. If action buttons only use icons, the
buttons are not accessible to screen readers. Sighted users can
see the printer icon on an action button and know they can press
it to print their document. Since the screen reader does not
have information about the icon, it only reads "button". If that
same action button was included in the Actions menu, it will
have a blank title. When a button does not contain a text label,
there is no way to determine the purpose of the button. The same
is true for buttons within forms. If there is no text label, the
screen reader will say "button".


2.2 Techniques

  * To create a text label for a hotspot button, select the
    button and open the Button Properties box. On the Button
    Info tab, go to the Button Label field and enter a name for
    the button.
  * To create a text label for an action button, select the
    button and open the Action Properties box. On the Basics
    tab, go to the Title field and enter a name for the button.
  * To create an "invisible" text label for a hotspot button,
    select the button. In the Button Properties box, go to the
    Button Label field and enter a name for the button. Change
    the color of the text label so it is the same color as the
    button. Change the font of the text to minimize the size of
    the button. This technique can be used when you want to keep
    the size of the button small and a sighted user can easily
    determine the button function. Assistive technology like a
    screen reader will still be able to read the text label,
    even though it is "invisible" to the sighted user.


2.2 Testing

  * Verify each button on the action bar contains a text label.
    It is not sufficient to have only an icon on the button.
  * Verify each button on the form has a visible text label.
  * If a button on the form does not have a visible text label,
    use Object Inspector to determine if the button has an
    invisible label.
    * Start Object Inspector
    * Place the mouse over the button with no text label. Verify
      there is a text value in the Name field.


3.1 Descriptive text for links

Provide descriptive text for all links, not just "click here".
Ensure each link makes sense when read out of context.

3.1 Rationale

A blind user must read documents sequentially with a screen
reader or use special navigation keys to navigate to each link.
When links say "go" or "click here" they don't make sense when
read out of context. If there are multiple links in a document
with the same text, you cannot differentiate the links without
going back to reread the document.


3.1 Techniques

Link text should be descriptive (more than "click here" or "go")
without being so wordy that it interferes with efficient
reading. Instead of writing

To return to checkpoint click here.

Make "return to checkpoint" the link.


3.1 Testing

  * Open the document which contains links in read only mode.
  * Navigate through the links. As each link is highlighted,
    verify the link text is understandable out of context.


3.2 Text pop-ups

Provide an alternative when using text pop-ups to display
information.

3.2 Rationale

Text pop-ups provide additional information about a field or
form. They cannot be accessed through the keyboard or a screen
reader, so some users cannot access information in the pop-up.


3.2 Techniques

Use one of the following techniques to provide an accessible
alternative to text pop-ups:

  * If the field is editable, include the information in the
    field help description.
  * Include the information in the on-line help documentation.
    Context sensitive help can be accessed through a Help action
    on the form.
  * Provide a button on the form which will display the
    information when pressed. The button can have the label "?"
    to minimize the amount of space on the form.
  * Add static text on the form to explain the field. For
    example, if you wanted to explain the input format for a
    date field:

          Date: (mm/yy/dd) _________________


3.2 Testing

  * Open the document which contains the text pop-ups.
  * From the Actions menu, choose View-Show-Field Help to
    display the Notes field help at the bottom of the window.
  * Access the first pop-up with the mouse. Verify the same
    information is available either through field help
    (displayed at the bottom of the window), a help button, or
    static text on the form.


4.1 Using color to convey information

Do not use color as the only way to convey information or
indicate an action.

4.1 Rationale

If color is used as the only way to convey information, users
who cannot identify or distinguish colors will not be able to
make use of the information. For example, asking users to press
the red button is not useful if they can't distinguish the red
button from other buttons on the screen. The software needs to
provide another way of making the information available in
addition to or in place of using color. For example, Notes
displays unread documents in the color red. But the unread notes
are also identified by an '*' in the first column; so someone
who cannot distinguish colors can still identify unread
documents.


4.1 Techniques

  * In addition to using color, provide a brief text
    description.
  * In addition to using color, include a text character to
    denote the information.
  * Use other attributes, such as bold or italics to distinguish
    text.


4.1 Testing

  * Identify where the application uses color to convey
    information and verify the information is provided in
    another way.
  * Print the document on a black and white printer and verify
    you can still understand the information that was conveyed
    in color on the screen.


4.2 Display values as icons

Do not use the option "Display values as icons" as the only way
to convey important information in view columns.

4.2 Rationale

In a view, the "Display values as icons" option can be used to
display a graphic icon in one of the view columns. Notes
provides a set of predefined column icons which can be used to
graphically represent special values in view columns. These
graphics are not accessible and cannot be read by screen
readers. For example, in the Inbox, there is a graphic to
indicate if a memo contains an attachment. The attachment
graphic is not read by the screen reader, but Notes does provide
an alternate way of viewing attachments using the By Attachments
view.

If important information is only provided through the use of an
icon, some users will not be able to view that information. For
example, in a Resume database there is a view to display
candidate documents which uses the "checkmark" icon to show
those candidates which have received a job offer and the "X"
icon to show those employees who have not received a job offer.
If there was no other way to identify job offer status in the
view, someone using a screen reader would have to open each
document to see who had a job offer.


4.2 Techniques

When using the "Display values as icons" option, it is important
to provide an alternative way of getting the same information.
When the column icon is only used to make certain documents
stand out in the view or to enhance the look of the view, it is
not necessary to provide an alternative way of viewing the
information. If the information is important, then the developer
should use one of the following techniques:

  * Include another view column with the text describing the
    information represented with the icon.
  * Provide an additional view with the information about the
    icon provided in text format.


4.2 Testing

  * Open the view(s) where icons are displayed in view columns.
  * If the icon is used to provide important information, verify
    the information is provided in an alternative method.
    * Does the view contain a column which describes the
      information represented by the icon?
    * Is there another view which provides columns or categories
      with the information represented by the icon?


5.1 Include forms in Create menu

Include forms in the Actions menu if they are needed by end
users to create new documents.

5.1 Rationale

Most applications allow users to create new documents using
action buttons or a navigator links. Since these objects are not
accessible, the form should be included in the Create menu or
the Action menu so it can be accessed from the keyboard or a
screen reader.


5.1 Techniques

  * To add a form to the Create menu, select the form and open
    the Form Properties box. Select the option "Include in
    menu". Then select "Create Menu" as the menu where the form
    will be included. The Create menu sorts form names in
    alphabetical order. If you want the form to appear in a
    different order, you can number the forms or rename them so
    frequently used forms are at the top of the list.
  * To add a form to the Action menu, identify the view where
    users will want to create new documents using the form. Open
    that View in design mode and choose Create-Action. In the
    Actions Properties box, enter a name for the action in the
    Title field. The name should be descriptive of the task like
    "Create Badge Request". Select the option "Include in Action
    menu". In the formula window, enter the formula to create
    the new document.
  * If the application has multiple forms beginning with the
    same letter, Notes will assign a default keyboard shortcut
    using the first letter not already used by another form. To
    ensure the accelerator key to access the form is meaningful,
    you may need to change the name of the form or force the use
    of a specific key. You can force the use of a specific key
    by typing an underscore before the letter you want to assign
    as the accelerator. For example, to make V the accelerator
    for the Interview form, enter "Inter_view" in the Name field
    of the form.


5.1 Testing

  * Identify documents that can be created by the end user in
    the database.
  * Verify the documents can be created using the keyboard.
    * Open the Create menu. Verify the form name is displayed in
      the list.
    * If the form is not in the Create menu, open the Actions
      menu. Verify there is an action displayed to create the
      document.


5.2 Field help

Provide short field help for all user editable fields on the
form.

5.2 Rationale

Field help gives users additional information to assist them
with filling out documents. The field help can tell users what
to enter in the field or how to use the field. While this is
useful to everyone, it is particularly important to someone
using a screen reader. If field help is not available, a sighted
user can always read the field label to understand the field's
general purpose. However, the field label is not always
accessible to a screen reader, so someone who is blind may not
know the label or the label that is spoken may not be correct.
The user must rely on the field help to tell them about the edit
field and to confirm the field label. Most screen readers
provide a special hotkey which allows Notes users to read the
field help line.


5.2 Techniques

When designing a new field, The text of the help should follow
these general guidelines:

  * Open the form and select the editable field where you are
    entering the help. Open the Field Properties box and select
    the Options tab. Write a brief description in the Help
    Description field.
  * Field help should be no longer than 4-6 words in length.
    Field help should be descriptive without being too wordy.
    When the field help is queried using a screen reader, the
    entire help line must be read. If the help is too long, it
    becomes non-productive and interrupts the reading of the
    rest of the document. For example, field help to enter the
    name of an interview candidate should say "Interview
    candidate's name." instead of "Enter the name of the person
    interviewing for this job".
  * Start the description with "Required" if the user must fill
    in the field to save the document.
  * Use words like Select if the field is requires making a
    choice instead of entering data. For example, "Select the
    language to be spoken."


5.2 Testing

  * From the Actions menu, choose View-Show-Field Help to
    display the Notes field help at the bottom of the window.
  * Open the document(s) with edit fields in edit mode.
  * Tab to each edit field. As you tab to the field, verify the
    field help is displayed at the bottom of the window.
  * If a field is not editable (e.g., computed or read only), no
    field help will be displayed.


5.3 Field labels

Associate labels clearly with controls and objects.

5.3 Rationale

A label provides the user with a general description about the
control, object or input area. In Notes, there is no way to
programmatically associate the field name for the control with
the static text label. Consequently, screen readers rely on
proximity of the label and the control to identify which labels
are associated with a control. If a label is too far away from
the control, it will not be spoken, or may be associated with
the wrong control.


5.3 Techniques

Place text labels immediately to the left or immediately above
the control.

  * If tables are used to align information, do not make the
    table columns which contain the labels too wide. If the
    label is too far apart from the control , it will not be
    identified correctly by assistive technology.


5.3 Testing

  * Test the database using a screen reader. Load a screen
    reader and then start Notes.
  * Using the keyboard, tab to each control in the document.
    Verify the screen reader speaks the appropriate label for
    each entry field.


5.4 Background patterns

Provide the capability for users to turn off patterned
backgrounds behind text or graphics.

5.4 Rationale

Notes provides the capability to paste graphics files as a
background for a form. While this may add to the visual appeal
of the form for most users, the background may make it difficult
or impossible for some users with visual impairments to read the
data on the form. Many users need high contrast between the
background and foreground objects like text and graphics in
order to read the documents.


5.4 Techniques

In Notes 4.6 and later, you can allow users to override the form
background. Open the Form properties and click on the Background
tab. Select the option "Allow users to override background
properties."


5.4 Testing

The background graphic or color for a form must be modified on a
document basis. You cannot modify the background in one document
and have it take effect for all documents. Each document must be
modified individually.

  * In Notes 4.6, open a document with a graphic background in
    edit mode.
  * Open the Document properties and select the Background tab.
  * Modify the background by changing color or removing the
    graphic background. If these options are grayed out, the
    background cannot be changed.


5.5 Window titles

Provide a descriptive title for each form.

5.5 Rationale

The window title is the text that appears in the title bar when
a user composes, reads or edits a document. The window title
helps users understand the context of the document they are
reading. If no window title is defined, the word "Untitled"
appears in the title bar. The window title can provide important
information about the document to someone who is blind. When the
screen reader reads items in the Window list, the first item
spoken is the Window title. This helps a user who is blind
determine if they have opened the correct document without
having to actually read through the document.


5.5 Techniques

Use the following techniques to provide descriptive window
titles for each form.

  * Open the form you are designing and select "Event: Window
    Title" in the design pane. Enter a window title (enclosed in
    quotes) in the formula window.
  * Define a window title which changes based upon the status or
    use of the document. For example, a different window title
    should be defined for new documents. Once the document has
    been created, the window title should include helpful
    information such as the date it was created or the status of
    the document

.


5.5 Testing

Testing should verify that there are no documents with a window
title of "Untitled" and that the window title is different for a
new document versus reading or editing an existing document.

  * Open a document. Verify the document has a valid window
    title (something other than "Untitled"). The window title is
    displayed in the title bar at the top of the screen.
  * Create a new document and save it. Verify the window title
    indicates that this is a new document. For example, "New
    Employee Document".
  * Open the document you just created. Verify the window title
    provides additional information about the document such as
    "Employee Document for Jane Doe".


5.6 Logical tab order

Provide logical tabbing order between fields in forms and layout
regions.

5.6 Rationale

Users who are blind or have certain motor disabilities must use
the keyboard to navigate an application. When using the
keyboard, you have to navigate sequentially through the
application, you cannot "skip" items. Random tab order can make
the form unusable. The tab order should be consistent with the
way you fill out a form. Typically the user starts at the top
left and moves towards the bottom right. It would not make sense
to tab to the first object to fill in your first name, and then
tab to the object to fill in the state and then back to the
object to fill in your last name.


5.6 Techniques

In general, the tab order should start at the top left and move
towards the bottom right. Use the following techniques to set
the tab order:

  * To set the tab order for fields in layout regions, open the
    form with the layout region. Click the first field in the
    layout region and choose "Design-Bring to Front". Select the
    next item in the tab order and choose "Design-Bring to
    Front". Continue with each field going in a logical order
    from top to bottom.
  * Tab order in forms is set implicitly when the form is
    designed. Make sure that the layout of the form is logical
    as you tab from object to object.


5.6 Testing

  * Unplug the mouse and navigate forms and dialog boxes using
    the keyboard.
  * Verify the order in which objects are navigated makes sense
    (usually top to bottom and left to right).


6.1 Alternate text for graphics

Provide text equivalents for important graphics.

6.1 Rationale

Adding text descriptions for graphics allows users who are blind
or those with text-only browsers to visualize the graphics.
Screen readers use the text description (alternate text) to
identify the images to the user. For users with graphical web
browsers, the text descriptions serve as placeholders for
graphics while the browser is loading the image.

The alternate text should be meaningful, like "home page" or
"search" or "products." When images are not links, use alternate
text carefully. A person having to listen to a document cannot
ignore text the way a person viewing the document can ignore a
picture. If images are not important or if they are redundant,
then do not include the alternate text, telling the screen
reader or browser to ignore the image.


6.1 Techniques

In Notes 4.6, you can provide alternate text for graphics.
Select the graphic and from the Actions menu select
Picture-Picture Properties. Under "Alternate text for Web and
deferred loading", type the text which summarizes the function
of the graphic. This feature is not available in earlier
versions of Notes.


6.1 Testing

Alternate text for graphics can be verified using Object
Inspector. As you mouse over the graphic, the Name or
Description field should display the description of the graphic.

  * In Notes 4.6, open the document which contains the graphics
    to be tested.
  * Start Object Inspector.
  * Move the mouse over the graphic. There should be a short
    description of the graphic in the Name field in Object
    Inspector.


Object Inspector

Object Inspector is an application provided by Microsoft as part
of the Software Development Kit (SDK) for Active Accessibility.
Inspector can be used to validate the aspects of accessibility
of software user interface elements which use Microsoftr Active
Accessibilityr or standard windows controls. It supports
software written for the Windows 9x, Windows NT or Windows 2000
platforms. Object Inspector can be downloaded as part of the
Microsoft SDK by going to
http://www.microsoft.com/enable/msaa/download.htm#SDK. There is
no charge to download and use the SDK.

Once the SDK has been installed, go to the Program Menu, select
Microsoft Active Accessibility SDK and then Inspect Objects.
When Object Inspector is loaded, it displays information about
the properties of an object as you select the object with the
keyboard or move the mouse over the object. If the software uses
Windows standard controls, or if the controls are non-standard
and MSAA has been implemented, Inspector will report the
information. If the software uses custom controls which are not
exposed through MSAA, the properties will be blank and that is a
failure for accessibility. The following properties may be
exposed by the application.

  * Name - a string used to identify, find or announce an object
    (e.g., text on a button or tab, prompt on an entry field).
  * Role - describes what kind of user interface element an
    object is (e.g., push button. radio button, check box, combo
    box, edit box, page tab).
  * State - describes an object's current status (e.g.,
    selected, focused, selectable, unavailable, checked,
    unchecked).
  * Value - represents visual information contained by the
    object. For example, the value for a link is the URL for the
    link, an edit field may have default text, the current item
    in a combobox.
  * Description - provides a textual description of object.
  * Help - provides information that tells the user about an
    object's function. This is typically used for balloon style
    information (e.g. ToolTips).
  * KeyboardShortcut - describes a key or key combination that
    will activate a specified object.
  * DefaultAction - describes the object's primary method of
    manipulation.

The graphic below shows a screen shot of Object Inspector when
the focus is on a button. For a selectable control, the
important properties are Name, Role and State. The value of the
Name property is "Yes" because that is the button label. The
Role property identifies the type of control, which in this case
is a push button. The value of the State property is "Normal"
because the button is not selected.

Using Object Inspector to verify selectable controls (e.g.,
radio buttons, check boxes, push buttons)

Selectable controls are accessible if they provide accurate
information about the following properties in Object Inspector.
If any of the following fields are blank, the software is not
accessible.

  * Name: The name associated with the control. For example, in
    Notes Mail, there is a checkbox to identify confidential
    memos. The value of the Name property should be IBM
    Confidential.
  * Role: The type of control (radio button, check box, push
    button).
  * State: The state should be one or more of the following as
    appropriate - checked, unchecked, default (to indicate
    default push button), normal, focused, focusable,
    unavailable.

Using Object Inspector to verify graphics

Graphics are accessible if they provide accurate information
about the following properties in Object Inspector. If any of
the following fields are blank for important graphics, the
software is not accessible.

  * Name: Text which describes the graphic.
  * Role: The type of control (graphic, link).
  * State: The state should be one of the following as
    appropriate - focusable, selectable, focused.
  * Value: The value of the URL for graphic links.

Using Object Inspector to verify edit controls

Graphics are accessible if they provide accurate information
about the following properties in Object Inspector. If any of
the following fields are blank, the software is not accessible.

  * Name: The text in the edit field. If there is nothing in the
    field, the Name property will be blank.
  * Role: The type of control (edit box, drop down list, combo
    box).
  * State: The state should be one of the following as
    appropriate - focusable, selectable, focused.
  * Description: The field label or help information about the
    control.

Screen Readers

Someone who is blind requires a screen reader to use a computer.
A screen reader makes information on the screen available as
synthesized speech or a refreshable braille display. Screen
readers can translate text information or graphics which have
alternate text describing the images. The ability of the screen
reader to read the software depends on the software's use of
standard operating system controls or accessibility APIs such as
Microsoft Active Accessibility (MSAA) for the Windows
environment.

Henter-Joyce, Inc. offers a free demonstration copy or a timed
evaluation copy of JAWS for Windowsr on their web site at
http://www.hj.com/. The free demo is fully functional for 40
minutes each time you start a new Windows session, and includes
the Eloquence for JFW speech synthesizer. The timed evaluation
copy is available for a nominal fee and runs for 60 days.

GW Micro offers a free demonstration copy of Window-Eyesr on
their web site at http://www.gwmicro.com/. The free demo is
fully functional for 30 minutes each time you start a new
Windows session. You have to restart Windows to continue to use
Window-Eyes for another 30 minutes.

 References and resources
  * Overview of the new Lotus Notes R5 accessibility features.
  * The Best Practices Guide for Lotus Notes 4.x

----------
>From the web page
http://www.austin.ibm.com/sns/accesshardware.html

Hardware accessibility

Hardware accessibility guidelines increase the accessibility to
hardware for people who have disabilities. Hardware includes
physical items like latches, keys, and physical input and output
connections.

Table of Contents:

Checklist for accessible hardware

References and resources

Follow this checklist to make your hardware accessible.

Please fill out all checklist items. Enter Y if the checklist
item is supported in the offering, N if not supported, and N/A
if not applicable to the offering. For all checklist items that
are not supported or not applicable, enter a brief explanation
in the comments section.

IBM Hardware Accessibility Checklist - Version 2.1

January 11, 2000


1.1 Accessible controls and latches

Controls and latches which are required on a regular basis for
system operation should be accessible and operable with one hand
and minimal dexterity.

1.1 Rationale

Users with little or no use of their hands or with limited reach
can have difficulty accessing and manipulating some controls.
System controls which are located at the rear of the system
cannot be operated by a user in a wheel chair or with limited
reach. A user with limited dexterity cannot use latches or
controls which require a twisting motion to activate them. A
user with one hand cannot open some laptop computers.


1.1 Techniques

Controls and latches used on a regular basis should be located
near the front of the system and need to have controls which are
easy to activate. "Regular basis" can be defined as those
controls which are required on a daily basis. The control to
turn on the system would be used on a regular basis. The control
to replace a hardfile would not be used on a regular basis. The
following techniques should be used for system controls used on
a daily basis.


* Locate controls on the front of the system for each reach.


* Use controls and latches which are easily differentiated
tactilely from the main surface of the product.


* The force required to activate the control should be no more
than 10 to 20 ounces for finger activation and 10 to 80 ounces
for palm activation.


* Use controls and latches which require light pressure such as:


* Up/down control buttons


* Concave rocker switches


* Sliding controls


* Concave buttons


* Avoid controls which require a twisting motion or a push and
twist motion.


* Avoid push-pull controls.


* Avoid controls which are required to be held down for a period
of time.


1.2 Concave buttons

Use concave buttons to assist mouth stick or head stick users.

1.2 Rationale

Concave buttons provide the easiest mechanism for a user using a
mouth stick or head stick to activate controls. These controls
are easy to differentiate and easier to activate.


1.2 Techniques

When possible, use concave buttons to activate controls.


2.1 Tactile landmarks on keys

Provide tactile landmarks on home row keys (e.g., F and J on
QWERTY keyboard, 5 key on the numeric keypad).

2.1 Rationale

Tactile landmarks provide a frame of reference, so users can
find and maintain their "home" location on the keyboard or
keypad.


2.1 Techniques

Provide tactile labels (nibs) on home row keys. Tactile labels
should be raised 1/32". It is better to provide the tactile
landmark on the key rather than above or below the key.

The home key(s) can be distinguished with different depth of
concavity.


2.2 Toggle key indicators

Provide a visual (or tactile) and auditory indicator of each
toggle key (e.g. Caps Lock) or make the state of that toggle key
available to software so that it can provide alternative
indicators.

2.2 Rationale

Toggle keys, like the Num Lock, Caps Lock and Scroll Lock keys
on the keyboard typically provide only visual feedback. A user
who is blind or visually impaired cannot determine the state of
those keys. The status should be provided in a redundant way so
a user who is deaf can see the state or a user who is blind can
hear or feel the state. If the state is available to software,
assistive technology can access the state and announce when the
toggle key is on or off.


2.2 Techniques

Toggle keys should use one or more of the following techniques
to make them accessible.


* Provide auditory feedback in addition to visual feedback of
the state of the key


* Provide tactile feedback on the state of the key


* Make the state available to software. This information can
then be used by assistive technology and some operating systems
to provide an audio indication of the state when it changes.

The UseToggleKeys setting in the Accessibility Options dialog of
Windows illustrates one method of providing an audio indication
of changing the state of

 toggle keys.


2.3 Industry standard layout

Provide an industry standard keyboard and keypad layout.

2.3 Rationale

An industry standard layout for keyboards and keypads makes it
easy for a user with a visual impairment to move to a new device
and be able to find the keys they need. For example, it would
not be a problem to change computers since most systems use the
standard QWERTY keyboard or the standard layout on numeric
keypads.


2.3 Techniques

Industry standard layouts include:
  * QWERTY layout for keyboards
  * 12 key Telephone Keypad
  * 17 key Numeric Keypad


2.4 Tactilely discernible keys

Provide keys which are tactilely discernible without activating
them (e.g., for flat membrane keyboards provide overlays).

2.4 Rationale

A user who is blind or visually impaired may have difficulty
distinguishing flat membrane keys or buttons unless there is a
tactile distinction between the keys. Users need to be able to
identify the keys without activating them.


2.4 Techniques

Keys can be located tactilely using one of the following
techniques.
  * Provide ridges around the keys.
  * Provide a bump or depression on the key.
  * Provide a keyguard or overlay option.


3.1 Accessible media

Allow frequently accessed media to be inserted and removed using
minimal reach and manual dexterity.

3.1 Rationale

A user with poor motor control or limited strength and dexterity
can have difficulty handling media or inserting the media into
drives. Frequently accessed media (e.g., diskettes or CD ROMs)
need to be easy to reach, insert, and remove.


3.1 Techniques

  * Locate drives on the front of the system for easy reach.
  * Removable media should eject and/or protrude far enough to
    provide clearance beyond the frame and cover overlap.
  * Pushbutton ejection systems which require low pressure allow
    for easy access to the media.
  * Allow receptacles to be repositioned or re-angled to be more
    reachable.
  * Whenever possible, allow the object to be inserted in
    several ways (e.g. a six-sided wrench can be positioned on a
    matching bolt six different ways; two sided keys can be
    inserted upside down).
  * Provide visual contrast between insertion point and the rest
    of the device (making a more obvious "target").
  * Clearly mark the proper orientation both visually and
    tactilely.


3.2 Loading and unloading media

Provide the capability to load and unload the media by
pushbutton, by pressing a keyboard key, or by software eject.

3.2 Rationale

Controls that are operable from the keyboard facilitate access
to these controls by individuals who are using alternate input
devices.


3.2 Techniques

  * Have the drive detect the presence of the media and
    automatically pull the media into the drive.
  * Beveled slots or edges facilitate insertion of cards,
    diskettes or CD's. Tactile and visual cues should also be
    provided to indicate the proper orientation of the object to
    be inserted.
  * The pushbutton should not be located below the media drive.


4.1 Industry standard ports

Provide industry standard ports for alternative input devices or
switches.

4.1 Rationale

A user with mobility impairments cannot use the standard
keyboard or mouse. The system needs to provide an industry
standard port (e.g., serial, parallel), so the user can attach a
switch or other alternate device to replace the keyboard. The
system would regard this device as its keyboard, and the user
would be able to input any valid keystroke combination available
from the regular keyboard.


4.1 Techniques

Provide an industry standard serial or parallel port which can
be used to attach alternate input devices.


5.1 Attaching large displays

Provide an option to attach larger displays through a standard
display connector.

5.1 Rationale

A user who is visually impaired can have difficulty seeing
normal text and graphics on the screen because the characters
are too small. By attaching a larger display, the size of the
screen is increased and allows for increased magnification of
the characters. The large display can work in conjunction with
software support for magnification.


5.1 Techniques

Provide a standard display connector to enable users to attach
larger displays which meet their needs. A standard video
connector or I/O slot that allows connection of a video control
card would satisfy this requirement.


5.2 Displays with non-glare and repositionable screens

Provide a non-glare screen and allow displays to be
repositioned.

5.2 Rationale

A user who is visually impaired can have difficulty seeing
normal text and graphics on the screen due to screen glare. By
repositioning the screen, the characters can have greater
contrast and be easier to see and read. The ability to
reposition the screen is also important for users in
wheelchairs, or with other physical limitations, who would need
to adjust the screen to their needs.


5.2 Techniques

Displays should be able to be repositioned so they can be viewed
by all potential users. Use non-reflective display surfaces to
minimize glare.


6.1 Color

Do not use color as the only way to distinguish keys or
controls.

6.1 Rationale

If the hardware conveys information by color alone, users who
cannot identify or distinguish colors will not be able to make
use of the information.


6.1 Techniques

Make color codes redundant with other codes by supplementing
color coding with text, shape or relative position coding. To
ensure that a color blind user will not miss any important
information, use colors that vary in intensity (have sufficient
brightness contrast).


6.2 Large lettering and high contrast colors

Use large, easily readable lettering and high contrast colors.

6.2 Rationale

A well-designed label enables the user to quickly scan a product
and find the item of interest. If the labels have small
lettering and are written in low contrast colors, a user with a
vision impairment may not be able to identify them.


6.2 Techniques

  * Where appropriate, provide large, easily readable lettering
    to facilitate the initial learning of equipment and the
    efficiency of operating occasionally used equipment.
  * Provide high contrast color labels. Light gray on slightly
    darker gray is stylish but does not provide sufficient
    contrast.
  * Where appropriate, provide tactile labels that have raised
    text or icons. Tactile labels should be raised 1/32".


7.1 System sounds

Provide an interface so that use of system sounds can be known
to software.

7.1 Rationale

Many systems use the speaker to announce warnings or errors to
the user. A user who is deaf or hard of hearing will not be able
to hear and respond to the warning. Systems need to provide an
interface so that software can provide an alternative method of
providing the information.


7.1 Techniques

Systems need to provide redundancy of important system sounds by
doing one of the following:
  * Provide an interface to system sounds for application use.
  * Provide a visual equivalent of the system sound (e.g.,
    flashing the screen, displaying the warning on the screen).


7.2 Volume control

Provide a physical volume control or provide an interface so
that volume can be controlled with software.

7.2 Rationale

A user with a hearing impairment can have difficulty hearing
auditory output and needs to adjust the volume so they can hear
the warnings and messages.

A user with a vision impairment may depend on speech output that
uses the system sounds.


7.2 Techniques

Volume control can be supported by:
  * Providing a physical volume control on the system,
    preferably the front. Provide visual and non-visual
    indication when the volume is in the off position.
  * Providing a software interface so the user can adjust volume
    through the software.
  * Providing an audio output jack on the system where
    appropriate; this is important for applications which use
    speech output as the standard interface. The user will need
    to adjust the volume so they can hear without disturbing
    others.


8.1 Accessible documentation

Upon request, provide documentation in an accessible format such
as ASCII text or HTML.

8.1 Rationale

Some users may not be able to access product documentation if it
is not in an accessible format.


8.1 Techniques

  * Upon request, provide product documentation in ASCII text or
    HTML format.
  * Include text descriptions of illustrations (graphics) in the
    documentation.

  * Considerations in the Design of Computers to Increase Their
    Accessibility by Persons with Disabilities Version 4.2 May,
    1988, Trace Research and Development Center.
  * The PC97 Logo Handbook contains Microsoft's recommendations
    for how to make computer hardware accessible.
  * Final report to the Access Board of the Electronic and
    Information Technology Access Advisory Committee.
  * Guidelines for the design of consumer products, and
    additional guidelines are available from the Trace Research
    and Development Center.
  * Resource Guide for Accessible Design of Consumer Electronics
    at http://www.eia.org/eif/toc.htm
  * Access to Telecommunications Equipment and Customer Premises
    Equipment by Individuals with Disabilities. TAAC Final
    Report.

----------
End of Document




